2001 Newsgroup postings (10/08 - 10/31) Lynn Wheeler

2001 Newsgroup Postings (10/08 - 10/31)

Disappointed
Why is UNIX semi-immune to viral infection?
Why is UNIX semi-immune to viral infection?
SUNW at $8 good buy?
mainframe question
mainframe question
mainframe question
mainframe question
mainframe question
mainframe question
E-commerce security????
mainframe question
mainframe question
mainframe question
mainframe question
Security Classifications? (Where to Find Info)
Disappointed
mainframe question
mainframe question
mainframe question
mainframe question
mainframe question
Web of Trust
mainframe question
mainframe question
mainframe question
voice encryption box (STU-III for the masses)
Indiana University and IBM Unveil the Nation's LargestUniversity-Owned Supercomputer
Indiana University and IBM Unveil the Nation's LargestUniversity-Owned Supercomputer
voice encryption box (STU-III for the masses)
mainframe question
voice encryption box (STU-III for the masses)
mainframe question
mainframe question
Processor Modes
Processor Modes
History
mainframe question
is this correct ? OS/360 became MVS and MVS >> OS/390
is this correct ? OS/360 became MVS and MVS >> OS/390
MVS History (all parts)
mainframe question
is this correct ? OS/360 became MVS and MVS >> OS/390
QTAM (was: MVS History)
QTAM (was: MVS History)
Processor Modes
MVS History (all parts)
five-nines
redhat 7.2 & gnome/nautilus
Virus propagation risks
What makes a mainframe?
Security standards for banks and other institution
Security standards for banks and other institution
mainframe question
mainframe question
mainframe question
hammer
mainframe question
hammer
Windows XP on quad DPS 8/70M?
RSA SecurID: public key cryptography?
MVS History (all parts)
ASR33/35 Controls
MVS History (all parts)

Disappointed

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disappointed
Newsgroups: comp.arch
Date: Mon, 08 Oct 2001 18:43:49 GMT

also, check the

[l/m 10/1/2001] news group dynamics comp.parallel (8/28) FAQ

posted today to comp.parallel & comp.sys.super newsgroup in the section that starts:


HOMEWORK: (academic students, undergrad, grads, post-grads)
-----------------------------------------------------------

If you are a student, in particular US/Canadian, or have an instructor,
homework places a quandary on the knowledgeable people in this group.
Students are supposed to do exercises, not have the readers of this group
do exercises for them.  Where the line between a homework query ends and
a serious research query begins is sometimes hard to define.

Point the following out to your instructor (this is one of the reasons
why you should read and be aware of news.announce.newusers (or de.newusers
or similar groups))

The best canned answer from another FAQ is:

>1A.  What about "I've got a school assignment...."
>
>Recently, I've been made aware of a USENET policy about posting news
>articles requsting info for a school assignment.  Michael Chui at Indiana
>University sent me the following info, which I have included
>verbatum and will try to stick to (since I agree with it)
>
>--------begin included text--------
>        From Michael Chui mchui@cs.indiana.edu
>

reference the rest yourself

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

Why is UNIX semi-immune to viral infection?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why is UNIX semi-immune to viral infection?
Newsgroups: comp.security.unix
Date: Mon, 08 Oct 2001 20:18:07 GMT

Barry Margolin writes:
And also don't forget about the old conflict between security and ease of use. While it's possible to make a system more secure without significantly impacting its ease of use, in many cases it can be pretty difficult. Much of the explanation for all the security problems in OE can be traced to giving higher priority to ease of use than security: it executes attachments automatically for the benefit of users who wouldn't know how to do this manually (curiously, though, AOL, which is probably used by the most naive users, still requires users to click on the "Attachment" button and save the attachment to disk and open it up with a separate program).

sometimes you can change the paradigm so that ease of use goes way up, the security goes way up, and simplicity goes way up (KISS)

misc. ref:
https://www.garlic.com/~lynn/aadsm7.htm#cryptofree

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

Why is UNIX semi-immune to viral infection?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why is UNIX semi-immune to viral infection?
Newsgroups: comp.security.unix
Date: Mon, 08 Oct 2001 22:39:56 GMT

Barry Margolin writes:
404 Not Found. There's an aadsm6.htm, but no aadsm7.htm.

oops, sorry about that ... fixed now.
https://www.garlic.com/~lynn/aadsm7.htm#cryptofree

the reference is related to discussion about security proportional to risk (thread from comp.security.misc)
https://www.garlic.com/~lynn/2001h.html#61

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

SUNW at $8 good buy?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SUNW at $8 good buy?
Newsgroups: comp.arch,comp.os.ms-windows.nt.advocacy,misc.invest.stocks
Date: Tue, 09 Oct 2001 12:12:27 GMT

peter@abbnm.com (Peter da Silva) writes:
I didn't mean "dumb" as a derogatory term. I think I've seen you on the net long enough that you might remember the "dumb terminal" ads Lear Seigler used to run (20 years ago) advertising the ADM3A. Sometimes it's smart to be dumb. :->

sometimes KISS works also ...

--
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, 13 Oct 2001 17:12:18 GMT

"Axl" writes:
First, I want to apologise if this question is totally out of line for this newsgroup. I am writing (attempting) a paper comparing and contrasting mainframes and PC's. High level stuff - a couple of pages. But, I have grown up in the PC world and have no clue about mainframes. There seems to be little information about them on the Internet, and absolutely nothing at the bookstore. If one of you kind gurus could just give me some comparison bullet points to research, I would be eternally grateful.

mainframe has taken on a number of attributes; one or more centralized resources "shared" by a number of parties ... also "batch" versus "interactive".

A lot of mainframe work consists of "batch", non-interactive oriented activity ... which the majority of industry, business, economy, people, etc are dependent upon. For instance, much of the payroll in the united states is a batch activity that happens on a mainframe at a predictable time & place .... isolated from the vagaries of actually needing some specific person to have sat down at some keyboard and performed some operation.

in fact, many people that are very orientated towards "interactive" computing would be very upset if a lot of the day-in, day-out things that they take for granted were to be moved out of an industrial strength environment to some interactive-oriented platform that was subject to the vagaries of human interaction.

misc reference to 100% uptime for 6+ years (from a couple years ago)
https://www.garlic.com/~lynn/99.html#71

i.e. people errors have become a significant percent of failure modes for industrial-strength applications that much of the economy id based on (and there is strong correlary that platforms that have evolved from desktop &/or interactive oriented platforms have a much toughter time adopted to the requirements of industrial strength computing ... aka, frequently not having implicit design points that require some sort of human action results in poorer dependability).

random mainframe ref:
https://www.garlic.com/~lynn/subindx2.html#mainframe
https://www.garlic.com/~lynn/subpubkey.html#mainframe

--
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: Sun, 14 Oct 2001 13:18:12 GMT

"Eugene A. Pallat" writes:
The kludgy way of doing thing that were trivial for TSS. Another OS would simply be another task running under TSS. No partitions needed. Those were a primitive methos desined for the old OS/360.

Gene Pallat

tss/360 paid for it ... at point when there were 30+ users on 360/67 with 30 users doing fortran edit/compiles/execute with subsecond response under cp/67 (& CMS), tss/360 on the same hardware with four users doing the same exact fortran/compiles/execute operations had 4-6 second response.

--
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, 14 Oct 2001 14:25:34 GMT

Anne & Lynn Wheeler writes:
tss/360 paid for it ... at point when there were 30+ users on 360/67 with 30 users doing fortran edit/compiles/execute with subsecond response under cp/67 (& CMS), tss/360 on the same hardware with four users doing the same exact fortran/compiles/execute operations had 4-6 second response.

then the trick was to get system optimization up so that it CP/67-CMS would support 75-80 users, still with subsecound response while the real storage stayed at 768kbytes i.e. 30-35 user CP/67 workload and 4 user TSS/360 workload cited was on 768kbyte 360/67 ... further optimization was able to hit 75 users in 768kbyte real storage while still keeping subsecond response ... and expanding workload type to include some memory hungry apps like cms/apl (apl/360 ported to CMS ... but instead of typical 32kbyte workspaces ... 1mbyte workspaces or larger). With 75-80 users on 768kbyte real storage ... there was actually only 104 4k "pages" left after fixed kernel and other requirements (out of the 768/4 = 198 total).

Part of the additional optimization showed up in the comparison of genoble science center changes for "working set dispatcher" to CP/67 which got almost the same exact performance on the same workload for 35 users on a 1mbyte (256 4k page, 155 4k pages after fixed storage requirements) 360/67 as cambridge machine did (with my dispatcher and memory management, & lots of other stuff) for cp/67 on 768kbyte 360/67 with 75 users (104 4k pages after fixed storage requirements vis-a-vis grenoble 155 4k pages after fixed storage requirements)

misc. ref:
https://www.garlic.com/~lynn/93.html#4 360/67, was Re: IBM's Project F/S ?
https://www.garlic.com/~lynn/93.html#7 HELP: Algorithm for Working Sets (Virtual Memory)
https://www.garlic.com/~lynn/94.html#1 Multitasking question
https://www.garlic.com/~lynn/99.html#18 Old Computers
https://www.garlic.com/~lynn/2001c.html#10 Memory management - Page replacement
https://www.garlic.com/~lynn/2001h.html#26 TECO Critique

random ref:
https://www.garlic.com/~lynn/subtopic.html#wsclock
https://www.garlic.com/~lynn/subtopic.html#fairshare

--
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, 14 Oct 2001 19:23:04 GMT

"Eugene A. Pallat" writes:
It appears that something on that copy of TSS was royally screwed up. At NASA, we could run 70+ users with FAST response. The dynamic scheduler algorithm may have been badly set up. Or ..... They may have wtitten very bad code. The dynamic scheduler was interesting in that it rewarded good programming practice and punished bad users.

I/O had fast allocation. All the task dis was issue an I/O call and had to wait for the interrupt while others would run. If you thrashed with page exceptions, you got dumped to the bottom of the queue. Compute bound jobs might get bypassed 10 to 20 times, but when they got dispatched, they would run 10 to 20 times as long.

The average FORTRAN programmer would average 200 page exceptions per second. With a little effort it would drop down to about 100. Knowing about hoe TSS worked internally, I would average between 17 to 20 page exceptions per second.

In short, sloppy coding practice was punished. Good efficient techniques were rewarded. We typically ran 60 to 80 interactive tasks plus lots of concurrent background tasks. On the 1110 with EXEC 8, the UNIVAC people thought is was doing well with 8 to 10 tasks running concurrently.

issue was at what release are you talking, what year, and what machine? However, working on os/360 internals, cp/67 internals, and tss/360 internals duing my undergraduate years in the 60s ... I made a lot more performance improvements in os/360 and cp/67 than i did on tss/360.

there was a lot of performance optimization done on tss (for tss/370) later in the '70s but in the '60s it was really abysmal over-all. furthermore, tss/360 was (by comparison) a real-storage hog. there was some benchmark that tss/360 on a 2mbyte, dual processer 360/67 had almost four times the thruput as a 1mbyte, single processor 360/67 (running the same workload mix) i.e. fixed storage requirements for basic tss/360 was nearing 768kbytes ... in theory, the two processor configuration should have had slightly less than twice the single processor configuration (all other things being equal ... basically penalty of SMP protocols in the multiprocessor machine). Getting nearly four times the thruput was a characteristic that tss/360 was severely real storage constrained even in a single processor, 1mbyte configuration. A dual-processor configuration, shared the same fixed kenel and storage ... so going from 1mbyte storage to 2mbyte storage probably increased storage available for applications by nearly four times or more (after accounting for kernel & other fixed storage requirements).

one of the reasons comparing tss/360 thruput on 768kbyte 360/67 against cp/67 on the same hardware was problem for tss/360 because tss kernel & other fixed storage requirements took up most of the machine. tss/370 had less of a problem later on on the larger 370s since its larger kernel & other fixed storage requirements was much less of an issue (i.e. both being small percentage of total real storage rather than tss/360 case of well over 50 percent of total real storage).

However, I was always able to benchmark higher thruput with either CP/67 or VM/370 thruput the lifetime of tss/370 (except for some relatively minor situations that the tss/370 group heavily optimized for ... and I might need to do a tweak or two to beat).

--
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, 14 Oct 2001 19:36:23 GMT

"Eugene A. Pallat" writes:
I forgot to mention that there was a 360/67 running UNIX that ran 5 times as many conncurent tasks as any other /67 running UNIX. The reason is that the core system was TSS which ran UNIX as a task.

If you are talking about the tss kernel that UNIX was ported to ... you are talking about tss/370 and most of the UNIX deployments were on 370/168 (or larger configurations).

somewhat random, unrelated ... unix ports to 370 machine came something like 10 years after 360/67 period that the mentioned tss/360 & cp/67 comparisons were done. first there was the port to late model interdata that had similar instruction set to 370 ... which came before actual port to real 370. At the time-frame of the tss/360 & cp/67 performance comparisons there was interdata/3 ... in another undergraduate project, used to build the first 360 plug compatable clone (originating the ibm 360 pcm industry)

360 pcm refs:
https://www.garlic.com/~lynn/submain.html#360pcm

--
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, 14 Oct 2001 19:47:25 GMT

random ref:
https://www.garlic.com/~lynn/subtopic.html#fairshare

although there was an in-joke for the resource manager:
https://www.garlic.com/~lynn/93.html#23 MTS & LLMPS?
https://www.garlic.com/~lynn/94.html#2 Schedulers
https://www.garlic.com/~lynn/94.html#5 Schedulers
https://www.garlic.com/~lynn/94.html#7 IBM 7090 (360s, 370s, apl, etc)
https://www.garlic.com/~lynn/94.html#52 Measuring Virtual Memory
https://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party
https://www.garlic.com/~lynn/99.html#155 checks (was S/390 on PowerPC?)
https://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager
https://www.garlic.com/~lynn/2001e.html#73 CS instruction, when introducted ?

where somebody in product marketing thot that there should be tuning knobs for the fairshare dynamic adaptive feedback scheduler (aka resource manager ... 25 years young earlier this year).

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

E-commerce security????

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: E-commerce security????
Newsgroups: comp.security,comp.security.pgp,alt.computer.security,alt.security,comp.security.unix,comp.security.linux
Date: Sun, 14 Oct 2001 19:54:01 GMT

"Ron Alexander" writes:
Do you ever order over the phone? If you do, you might want to understand about scanners. You are MANY orders of magnitude more secure on a secure web server than on your phone.

issue hasn't been the transactions in flight ... it is the exposure with web merchants to gain access to the merchant transaction master file (something that is a little bit harder to obtain with non-web-based merchants).

misc. refs:
https://www.garlic.com/~lynn/subintegrity.html#fraud Risk, Fraud, Exploits

random refs:
https://www.garlic.com/~lynn/aadsm2.htm#keyl2 On leaving the 56-bit key length limitation
https://www.garlic.com/~lynn/aadsm6.htm#terror [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm6.htm#terror3 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm6.htm#terror7 [FYI] Did Encryption Empower These Terrorists?
https://www.garlic.com/~lynn/aadsm7.htm#cryptofree Erst-Freedom: Sic Semper Political Cryptography
https://www.garlic.com/~lynn/aadsmore.htm#setjava javasoft SET - NO!
https://www.garlic.com/~lynn/ansiepay.htm#breach Security breach raises questions about Internet shopping
https://www.garlic.com/~lynn/2000c.html#59 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000g.html#25 SSL as model of security
https://www.garlic.com/~lynn/2000g.html#33 does CA need the proof of acceptance of key binding ?

--
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, 14 Oct 2001 20:12:53 GMT

Anne & Lynn Wheeler writes:
when they came up with the (new) tss/370 scheduler ... I used to kid the person that if it was really dynamic adaptive ... then it wouldn't need setting up ... it should be able to figure it out by itself; something that I had done for fairshare dynamic adaptive feedback scheduling ... originally when I was undergraduate ... and then later shipped in both cp/67 and vm/370

the tss (& mvs ... there is some mvs story in the archive someplace) adaptive scheduler was a "table-driven" scheduler ... you set up all the entries in the table telling the scheduler what to do under any given cicumstance, process could come into the table with no-prior history and eventually get to some entry ... then once in some entry there were lots of avenues that might be taken given that you were at some entry and various things happened. it was dynamically adaptive in the sense that scheduling decisions weren't just made on what some current state or even happened to be ... but also what current scheduling table entry a process might occupy (which was in some sense an aggregation of sequence of prior events)

both MVS & TSS groups had huge benchmark activities which had a variety of different workloads that were then performed under a semi-random walk of different table configurations ... searching for optimal table settings for the various workloads.

by the comparison, the cp/67 & vm/370 (fairshare, dynamic adaptive, feedback) schedulers that I produced ... modified their own values (effectively) based on success of previous periods (although the structure didn't look like either the MVS or TSS table schedulers). This genre of schedulers had policies objectives that could be specified, and then the internals managed dynamically (based on dynamic system & process-specific activity) the structures that were analogous to the MVS & TSS (static) scheduling table structures ... aka when I talked about dynamic adaptive and when TSS talked about dynamic adaptive we were talking at totally different level of dynamic adaptive.

--
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: Mon, 15 Oct 2001 00:12:13 GMT

"Eugene A. Pallat" writes:
OS/360 desperately needed improvements. Much of TSS and improvements were made at NASA Lewis. If you worked with TSS then you should have known Hugh DeVore, Steve Kiseli, Gale Ames (think gale pages), etc. Hugh was quite a character. He was one of the few people I knew who I would consider a genius in systems software.

should i tell some of my hugh stories ... while i was still in school (i think early TSS release levels starting around 0.50 and up) ... or after i graduated and joined cambridge. i worked with some of the YKT people then on their installation.

I was part of the cp/67 announcement (although still an undergraduate) at spring Share '68 in Houston ... but also active in os/360 and some TSS. Hugh and I got into real good argument one night after having spent most of the night drinking at SCIDS ... it came very close to turning physical. We met at the astrodome the next day (on neutral turf?).

--
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: Mon, 15 Oct 2001 11:21:39 GMT

"Eugene A. Pallat" writes:
There was one time where he was near NAPA valley and no one could find him. One time he disappeared for a whole month. When he resurfaced, he had completely written disk I/O and error recovery and it WORKED! It was a tragedy that he died so young.

it took me longer than a month to rewrite IOS and various error recovery for the disk engineering lab ... so they could use operating system for testing engineering models under development (nominal mean-time-to-failure of MVS with single test cell was 10-15 minutes, objective was to be able to support a dozen or so test cells concurrently).

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

--
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: Mon, 15 Oct 2001 14:10:14 GMT

jcmorris@mitre.org (Joe Morris) writes:
How about an operational definition: a mainframe is a computer operated and maintained by people hired full-time for that purpose, and who are not the persons (plural) who use its services for data processing?

This definition deliberately includes X86 systems in server farms. If you want to exclude such small fry, you'll have to restrict the definition further by requiring that the machines be too expensive for most companies to own more than one or two, but such a restiction would be very subjective.

some of the "mainframe" issues could be considered cultural ... for instance, a single installation's disaster recovery plan ... might have more documentation than some non-mainframe operating system total documentation ... whole series of cultural industrial strength computing issues that many people don't even know that they don't know.

another simple example is industry-wide error reporting service ... i.e. capturing the detailed error statistics for every machine at every installation and reporting summaries comparing different mainframes from different vendors.

I had somewhat run afoul of such an issue ... a particular new mainframe model was projected to have a total of 3-5 errors of a certain kind of I/O error (somewhat akin to a SCSI bus error) for a period of a year across all machines of that model shipped (i.e. not 3-5 per day or month ... and not 3-5 per machine ... but 3-5 total for all machines over a period of a year).

The industry wide reporting service showed up with something like 15 such errors being recorded total for a whole year across all machines of that new model (i.e. original 3090). This resulted in a big investigation which turned out that some software that I had designed sometime previously for channel extension over telco T1 simulated that kind of error in place of a telco transmission error.

Now, how many non-mainframe machines have all errors that occur on the machine recorded and kept and the reports reviewed by data processing staff at regularly scheduled daily, weekly, and monthly basis for all such machines at the installation. Furthermore, what other non-mainframe machine markets have a industry-wide service that collects all such reports from all customers from all machines and produces regular reports of the summaries.

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

Security Classifications? (Where to Find Info)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security Classifications? (Where to Find Info)
Newsgroups: sci.crypt
Date: Sat, 13 Oct 2001 18:32:43 GMT

Mok-Kong Shen <mok-kong.shen@t-online.de> writes:
Addendum: The following is a relevant URL:

http://www.commoncriteria.org/
https://web.archive.org/web/20020124205623/http://www.commoncriteria.org/

somewhat aside, i've done a security glossary merge from orange book, common criteria 1.0, 2., several internet RFCs, and a number of other sources
https://www.garlic.com/~lynn/index.html#glossary

Security Terms merged from: AFSEC, AJP, CC1, CC2, FCv1, FIPS140, IATF IEEE610, ITSEC, Intel, JTC1/SC27/N734, KeyAll, MSC, NCSC/TG004, NIAP, RFC1983, RFC2504, RFC2828, TCSEC, TDI, TNI, and misc. Updated 20010729 with glossary from IATF V3.

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

Disappointed

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disappointed
Newsgroups: comp.arch
Date: Wed, 10 Oct 2001 19:27:04 GMT

"Bill Todd" writes:
I do, since I well remember 15 - 20 people logged onto a PDP-11/45 with 248 KB of memory assembling, playing games, word-processing (if you consider TECO to be a word processor, anyway)... Though it didn't take more than 3 concurrent COBOL compiles for response times to dive.

we were able to get 70-80 on 786kbyte 360/67, edit, assembling, word-processing (GML ... precursor to SGML, HTML, XML, etc), APL/360, fortran compile, virtual operating systems, etc. ... & subsecond response time for trivial interactive.

random refs
https://www.garlic.com/~lynn/subtopic.html#545tech 545 tech sq, camb. sci cntr
https://www.garlic.com/~lynn/subtopic.html#hone APL & HONE
https://www.garlic.com/~lynn/subtopic.html#fairshare performance, scheduling
https://www.garlic.com/~lynn/subtopic.html#wsclock working set, paging

--
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, 16 Oct 2001 12:47:59 GMT

cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:
I was under the impression that there were (are?) two versions of Linux/390, one which needs VM-assists to run and the other which will run native, and Amdahl's IBM-alikes run their own flavour of UNIX without any issues. Not that I can see what difference running UNIX (or similar) makes, other than operating system snobbery (UNICOS, anyone?)

there was also UNIX kernel that was severely modified to run in the tss/370 kernel ... that saw pretty extensive deployment inside AT&T (aka much of the UNIX kernel was replaced with tss/370 kernel). if it was at&t ... was it unix?

ibm also had aix/370 (& aix/ps2) which was actually locus kernel running on both 370 and ps2 (sort of unix flavor of SAA)

--
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: Tue, 16 Oct 2001 14:41:32 GMT

Wild Bill writes:
Bell Labs devoted many hours of research, testing, and many dollars for hardware to develop and implement Unix/370. It did indeed run on a stripped TSS/370 kernel. They could get, at most about 50 users logged in and doing things. TSS on the same hardware could handle about a hundred. And VM, also on the same hardware could do 200. (Pesonally, I think it was the fault of the C compiler someone "threw together" after thay had an "Oh Sht! We forgot about that!" epiphany.)

After those dismal numbers the Lab abandoned further development.

Then Amdahl showed up with UTS a couple of years later, got it installed in a half-dozen systems. One of which was even IBM iron!

i had a friend at one of the chip shops in the valley who started with the bell 370 c compiler to port various bezerkely chip tools to vm/370 ... he eventually did (had to do) a total rewrite of the code-gen/optimizing code (as well as fixing large number of bugs). he also did a lot of the work on the compiler that was chosen by ibm to logo as its (first mvs&vm) 370 C compiler.

i believe the uts/gold work can be traced back to a port of unix to 370 at princeton.

misc gold refs:
https://www.garlic.com/~lynn/99.html#2 IBM S/360
https://www.garlic.com/~lynn/99.html#190 Merced Processor Support at it again . . .
https://www.garlic.com/~lynn/99.html#191 Merced Processor Support at it again . . .
https://www.garlic.com/~lynn/2000c.html#8 IBM Linux
https://www.garlic.com/~lynn/2000f.html#68 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2000f.html#70 TSS ancient history, was X86 ultimate CISC? designs)

--
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: Tue, 16 Oct 2001 14:58:21 GMT

cbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:
Ages ago, when AIX/370 was still current, I remember hearing a story that it needed VM assists not for any technical reason, but because IBM wanted to prevent a version of UNIX running native on their hardware for various nefarious reasons... any truth in this one?

the story down thru the years (not just unix on mainframes) is that (quality) device drivers, error recovery, erep, etc are really, really expensive. there have also been sporadic efforts to consolidate such components across all the varied operating systems (vm, mvs, vs1, dos/vs, etc). aix/370 under vm could let vm handle all the really gorpy stuff. Little things like if the error analysis & error prediction (based on soft/recoverable errors) reports aren't done in a very specific way ... or the sequence of commands weren't just so for maint. ... field engineering wouldn't agree to support/maintain/service the hardware.

there would have to be a very significant customer install base & revenue to just cover the upfront costs of training & supporting all the field engineering support/maintain/service (aka RAS) requirements. Such costs would be significantly larger than all the other costs for aix/370 port/product combined.

random refs with respect to rewriting in order that disk engineering development & test could be done under operating system environment:
https://www.garlic.com/~lynn/subtopic.html#disk

--
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: Tue, 16 Oct 2001 15:15:18 GMT

Wild Bill writes:
Bell Labs devoted many hours of research, testing, and many dollars for hardware to develop and implement Unix/370. It did indeed run on a stripped TSS/370 kernel. They could get, at most about 50 users logged in and doing things. TSS on the same hardware could handle about a hundred. And VM, also on the same hardware could do 200. (Pesonally, I think it was the fault of the C compiler someone "threw together" after thay had an "Oh Sht! We forgot about that!" epiphany.)

the question of VM performance has always been a sore spot in some places. CERN was an early VM installation (side note .. could be considered significant in the fact that both VM and GML originated at Cambridge ... and GML originally on VM, then effectively begate SGML, HTML, XML, etc).

Circa 1974, CERN did some detailed benchmark comparisons between VM/CMS, MVS/TSO and some number of other offerings ... that showed VM/CMS with significant performance & thruput advantage. Reports were made available to Share ... but the reports made available to IBM were immediately classified (by the MVS group) Confidential, Restricted ... i.e. only available to employees on a need-to-know basis.

--
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, 16 Oct 2001 19:09:39 GMT

Steve O'Hara-Smith writes:
If the design costs are a significant fraction of the unit price it might be a mainframe.

if RAS is a significant fraction of the unit price, it might be a mainframe

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

Web of Trust

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Web of Trust
Newsgroups: sci.crypt
Date: Wed, 17 Oct 2001 01:08:07 GMT

"Roger Schlafly" writes:
I wonder how many systems really worry about this even in a hierarchial PKI. Eg, suppose Fred buys a ordinary cert from from Verisign, and uses it to issue a cert to Bill. Bill then has a cert chain leading back to a trusted root CA. Only closer examination will reveal that Verisign knows nothing about Bill. Will the commonly used validity checks catch this?

the main prevalent use of certificate PKI operations (possibly reaching 99.99999999 percent of certificate PKI operations done in the world today) involve SSL domain-name server certificates. They contain the domain name of the server so that the client can cross-check the domain name in the certificate with what the client specified in their http specification (i.e. is the server i think i'm talking to really the server that i expect).

the supposed reason for these domain name server certificates are concerns regarding the integrity of the domain name infrastructure (i.e. the domain name infrastructure might not be pointing me at the correct server).

so, how does domain name server certificates come about? somebody goes to one of the certification authorities (CAs) and requests a certificate with that domain name. Since the certification authority is the authoritative agency for domain names ... the certification authority must contact the authoritative agency for domain names to validate that the entity requesting the domain name certificate is actually responsible for that domain name. Who is the authoritative agency for domain names that the certification authority needs to contact??? Well the certification authority has to contact the very same domain name infrastructure that everybody is concerned about with regard to its integrity. That leads to a little more concern by the certification authorities about trusting the authoritative agency for domain names for their certificates ... even tho this trust issue is the justification for having those certificates in the first place (does anybody hear the term catch-22??).

Ok, so one of the proposals to improve the integrity of the domain name infrastructure is to have people register a public key when they register their domain name (then any subsequent updates have to be signed with the corresponding private key). Now this improves many of the integrity issues and concerns of the certification authorities (CAs) regarding trusting the domain name infrastructure as the authoritative agency for domain names.

However, if the integrity of the domain name infrastructure is improved such that the certification authorities can trust them, then it is possible that the rest of the world could also ... eliminating the reason that everybody is getting all these certificates.

Furthermore, if the domain name infrastructure improved their integrity and also registered public keys ... not only could people start to have more trust in the domain name infrastructure (not just the certification authorities) ... but the domain name infrastructure could start acting as a real-time server of trusted public keys (effectively using existing domain name infrastructure protocol and facilities). This would also subsume the second function of certificates, trusted distribution of keying material.

misc past threads on this subject:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

--
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: Wed, 17 Oct 2001 16:38:01 GMT

genew@mail.ocis.net (Gene Wirchenko) writes:
If it has an office inside of it, it might be a mainframe.

if it can simultaneously run 97,000 copies of linux ...

ran across this in a recent announcement for a talk at comdex

Founded in 2000, Sine Nomine Associates, Inc. (SNA) provides a comprehensive range of internetworking, telecommunications, strategic, and training services for organizations in all commercial and government sectors worldwide. We are also shaping the cutting edge of the Linux for System/390 revolution, using Linux for System/390 as a reliable and stable solution for mission-critical Internet support services. Our successful and unsurpassed test of over 97,000 Linux images on a single System/390 system remains the flagship leading the industry into the virtual server/virtual network environment.

--
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, 18 Oct 2001 14:07:31 GMT

"Eugene A. Pallat" writes:
That was a unique advantage of TSS. It was designed to run on up to a 4x4 system - 4 CPUs and 4 channel controllers. A dead CPU and/or channel didn't stop the system. It also degraded gracefully if there were problems in a core box.

the 360/65 was originally announced as 360/60 (i.e. m30, m40, m50, m60, etc) and the 360/67 as a 360/62. I believe that the change from 60/62 to 65/67 was an upgrade of the memory technology to 750mics core. Someplace I had a old SRL for 360/62 showing four processor configuration, however, I believe that no four processor models were ever built and I'm only aware of a single three processor being built.

Charlie (responsible for compare&swap ... there was a couple month effort to come up with that nmenonic which are charlie's initials ... CAS) was the system engineer at the customer (gov. instlallation) that had the three-processor machine (until it got canceled). The channel controller for the three-processor (i believe) was unique in that all possible switches were software programmable (not just sensing in the control regs ... but also setable). some blue-card ref:
https://www.garlic.com/~lynn/2001c.html#15 OS/360 (was LINUS for S/390)

The channel controller (for multiprocessor configurations) disappeared in 370 (as did >24bit addressing support, 360/67 had support for both 24bit virtual and 32bit virtual address). Much reduced function re-appeared somewhat as the channel director for the 303x machines ... and >24bit support didn't show-up until 3081 as 31bit addressing (not 32bit).

It is interesting how much of all of this originated at 545tech sq. in cambridge. ctss was the mit time-sharing system which begat both Multics and CP/67 (both projects in 545 tech. sq). The (ibm) boston programming center was moved to 545 tech sq which was responsible for CPS (conversational programming system). And of course there is the stories about Multics being the genesis of unix. out of cp/67 came vm/370, lpars, etc. Also out of 545 tech. sq came GML which begat SGML, HTML, XML, etc. A lot of the early work evolving from performance tuning into capacity planning also came out of CSC work at 545 tech sq.

melinda's history paper with various CTSS & time-sharing lore:
https://www.leeandmelindavarian.com/Melinda#VMHist

misc. other 545 tech sq & CSC references:
https://www.garlic.com/~lynn/subtopic.html#545tech

misc. smp references:
https://www.garlic.com/~lynn/subtopic.html#smp

misc. perf references:
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock

project that would have sort-of used portions of the TSS kernel (somewhat similar to the way the AT&T unix effort did)
https://www.garlic.com/~lynn/2001.html#27 VM/SP sites that allow free access
https://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party

one of the things for the above, I had a program (that I had written in PLI) that did detailed register usage & control flow analysis of assembly listing and also produced a high-level language psuedo-code representation of the listing. One of the differences between standard os assembly listings (F, H, etc) and TSS listings was that the addr1/addr2 addresses on the statement line was tag'ed with the csect/dsect number (making mapping to symbolic pointer-> generation slightly more deterministic)
https://www.garlic.com/~lynn/94.html#12 360 "OS" & "TSS" assemblers
https://www.garlic.com/~lynn/2000d.html#36 Assembly language formatting on IBM systems
https://www.garlic.com/~lynn/2000f.html#60 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
https://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001h.html#59 Blinkenlights
https://www.garlic.com/~lynn/2001h.html#76 Other oddball IBM System 360's ?
https://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
https://www.garlic.com/~lynn/2001l.html#5 mainframe question

--
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, 18 Oct 2001 15:26:40 GMT

Anne & Lynn Wheeler writes:
project that would have sort-of used portions of the TSS kernel (somewhat similar to the way the AT&T unix effort did)
https://www.garlic.com/~lynn/2001.html#27 VM/SP sites that allow free access
https://www.garlic.com/~lynn/96.html#4a John Hartmann's Birthday Party

the above project was to be a interative, rapid-development micro-kernel effort. when it started to look like the project (not the kernel) was going for large scale bloat ... i tried another approach.

cp/67 could be considered the original micro-kernel ... but by the time of the above project there was about 40+klocs in the TSS kernel and something like 270+klocs in the vm/370 kernel. One of the unfortunate side-effects of a really well-designed, compact micro-kernel ... was it was so easy to clutter it up with new quick&dirty code ... aka since the basic code was so well-designed and clean that it was trivial to add new stuff w/o getting all tied into knots over trying to figure out spaghetti code. While it was simpler to add quick&dirty code this way (rather than do detailed architecture consistency), over period of 10-20 years, it eventually bloated the pure micro-kernel into spaghetti code.

part of this can be considered the price of success ... while the number of TSS customers (and correspondingly the number of developers working on the code) drastically decreased ... the number of vm/370 customers and developers significantly increased. It is a lot harder to maintain architecture & design consistency when there are a large number of developers throwing everything, including the kitchen sink into the microkernel (especially when large number of the new developers had traditional operating system background rather than microkernel orientation ... more in common with hardware processor engineers of the time than operating system developers).

since ZM activity was floundering under its own weight, i tried an alternative demo of moving major function out of the existing kernel. I selected for the demo, the VM spool file subsytem. Part of the reason for this selection was that the internal network support had a large part built on the VM spool file subsystem ... and it had become a major thruput bottleneck for internal high-speed network (& some HSDT related activities). The activity was suppose to demonstrate moving major function out of the kernel, increase the spool subsystem performance by a factor of ten times and also add support for asynchronous API semantics (in addition to the synchronous API semnatics).

misc. high-speed data transport (HSDT) refs:
https://www.garlic.com/~lynn/subnetwork.html#hsdt

misc. network refs:
https://www.garlic.com/~lynn/subindex.html#network
https://www.garlic.com/~lynn/subindx2.html#network
https://www.garlic.com/~lynn/internet.htm

random refs:
https://www.garlic.com/~lynn/94.html#22 CP spooling & programming technology
https://www.garlic.com/~lynn/94.html#29 CP spooling & programming technology
https://www.garlic.com/~lynn/99.html#34 why is there an "@" key?
https://www.garlic.com/~lynn/99.html#36 why is there an "@" key?
https://www.garlic.com/~lynn/99.html#213 Why is Pascal no longer a leading development Language?
https://www.garlic.com/~lynn/2000.html#15 Computer of the century
https://www.garlic.com/~lynn/2000b.html#42 Why are Suns so slow?
https://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)
https://www.garlic.com/~lynn/2001b.html#30 perceived forced conversion from cp/m to ms-dos in late 80's
https://www.garlic.com/~lynn/2001c.html#35 How Commercial-Off-The-Shelf Systems make society vulnerable
https://www.garlic.com/~lynn/2001e.html#31 High Level Language Systems was Re: computer books/authors (Re: FA:
https://www.garlic.com/~lynn/2001e.html#76 Stoopidest Hardware Repair Call?
https://www.garlic.com/~lynn/2001f.html#63 First Workstation
https://www.garlic.com/~lynn/2001j.html#4 I hate Compaq

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

voice encryption box (STU-III for the masses)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: voice encryption box (STU-III for the masses)
Newsgroups: sci.crypt
Date: Thu, 18 Oct 2001 18:53:28 GMT

daw@mozart.cs.berkeley.edu (David Wagner) writes:
Unfortunately, there are ways to spoof Caller ID.

For instance, I believe various hackers -- Mitnick, Poulsen Masters of Deception, and so on -- are known to have successfully hacked into phone switches, which is enough to fake out Caller ID. I believe there are other ways, too.

So Caller ID seems like a reasonable thing to add to the pot, in the time-honored belt-and-suspenders philosophy, but I wouldn't rely on it alone to defend against motivated attackers.

if you hack into the infrastructure ... you can subvert almost any authentication scheme ... for instance the server domain-name PKI certificates can be subverted by hacking the domain name infrastructure with a domain name hijack ... and then applying for a PKI certificate for that domain name. Since CAs have to rely on the domain name infrastructure as the authoritative agency as to domain name ownership ... it is then possible to get issued a valid certificate for that domain name.

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

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

Indiana University and IBM Unveil the Nation's LargestUniversity-Owned Supercomputer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Indiana University and IBM Unveil the Nation's LargestUniversity-Owned Supercomputer
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 18 Oct 2001 22:10:21 GMT

EBIE@PHMINING.COM (Eric Bielefeld) writes:
Very interesting. Does anyone know why IBM has to go to a Unix box to make a supercomputer? Why can't they do it on z/OS?

random ref:
https://www.garlic.com/~lynn/2001i.html#52

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

Indiana University and IBM Unveil the Nation's LargestUniversity-Owned Supercomputer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Indiana University and IBM Unveil the Nation's LargestUniversity-Owned Supercomputer
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Fri, 19 Oct 2001 00:21:40 GMT

sknutson@LANDMARK.COM (Sam Knutson) writes:
Most Super Computers are involved in Numeric Intensive Computing and IBM mainframes long ago abandoned this ground to the multi-node UNIX based or specialized systems that handle it better. z/OS and zSeries hardware don't handle these kind of workloads well but then ASCII White is poorly suited to run billing for MCI:-)

i think there are some flex/os installations that are doing just that type of stuff ... including driving the printers. part of it my be legacy cobol apps.

Other issues are that some number of these large account based stuff are vsam and possibly in some cases even bdam (don't translate well into things like RDBMS that would somewhat level the playing field with other platforms).

the bigger differentiator isn't so much whether it can run the application ... but whether or not there is a high level of confidence that the application runs on schedule each and every time. there is a significantly larger RAS issue in many of these applications ... extending all the way up into thru most of the application.

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

voice encryption box (STU-III for the masses)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: voice encryption box (STU-III for the masses)
Newsgroups: sci.crypt
Date: Fri, 19 Oct 2001 00:46:47 GMT

Paul Rubin <phr-n2001d@nightsong.com> writes:
The analogy is bogus though. Compromising a CA requires, well, compromising the CA. Spoofing Caller ID requires simply plugging a PBX into the phone system that can generate caller ID codes. (PBX's can set the caller ID numbers of outgoing calls, so that when you call someone from your office phone, the PBX can assign the call to any of a pool of outgoing phone lines, and the recipient can still see your office phone number on their Caller ID). Caller ID doesn't try to be secure in any nontrivial way.

compromising a CA requires compromising the CA and/or any infrastructures that the CA is dependent upon for correct operation.

If a CA is critically dependent on some external agency as to the validity of the information that it is certifying ... and it is possible to compromise that external agency ... then the internal operation of the CA can be at the very highest security level ... and you still can't trust the CA's certification.

For most of the CAs out there they merely attest to having gone thru some sequence cross-checking some information that they've been asked to certify. For the most part CAs are not the final authority as to the information that they've been asked to certify ... aka somebody comes in and asks a CA to provide a certification as to some claimed binding. In effect, the CA doesn't actual certify the validity of the information in the certificate ... they just claim that they have followed various checking procedures as to the validity of the information ... but not necessary to the actual validty of the information itself. In most cases, CAs are dependent on other agencies who are the authority agency as to the actual validity of the information.

A trivial example is I ask a CA to certify my caller-ID (i.e. I assert a caller-ID and ask a CA to manufactur a certificate as to that caller-ID). If i've been able to compromise the Caller ID system ... they will check as to the Caller ID and it will come up good.

Similarly is the situation with SSL domain-name certificates (previously cited) ... where a CA is dependent on checking with the domain name infrastructure as to the validity of some claim with regard to domain name ownership. As to "identity" certificates, they can be dependent on something like driver's license. There have been statements by various states as to their ability to prevent identity theft with regard to false driver's licenses. So, easy question what is the frequency of caller-id compromise vis-a-vis identity theft frequency.

A CA isn't infallible, and in fact, they tend to disavow all liability with what they certify ... possibly in part because for the most part they have absolutely no control over the information they are placing in a certificate (and it is likely that very few of the agencies that CAs deal with regarding the validity of the information that they are certifying are interesting in accepting liability on the part of the CA).

--
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: Fri, 19 Oct 2001 03:33:58 GMT

lwinson@bbs.cpcn.com (lwin) writes:
Unfortunately, IBM was slow in upgrading its tape drives for S/360; it used mostly warmed over 7000 series units. Due to anti trust pressures, IBM unbundled and allowed customers to attach 3rd party units. This exploded that marketplace, and vendors such as Memorex jumped in and sold lots of tape drives with significantly better price-performance. (The 1403 printer was also warmed over from the 1401 (though with more speed); but it was so good and popular it remained in service and very popular into the S/370 era.)

unbundling was june 23rd, 1969 (basically services). we had started on project building the first ibm pcm controller prior to that ... somewhat reverse engineering the channel interface and building our own channel interface board (credited with originating the PCM controller business). it was into the 370 era before pcm controller & devices became prevalent.

random pcm ref:
https://www.garlic.com/~lynn/submain.html#360pcm

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

voice encryption box (STU-III for the masses)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: voice encryption box (STU-III for the masses)
Newsgroups: sci.crypt
Date: Fri, 19 Oct 2001 04:30:29 GMT

daw@mozart.cs.berkeley.edu (David Wagner) writes:
Then it's not properly implemented.

I'm pretty sure I pointed out the requirement for proper implementation earlier in the thread. I really don't understand your point.

in effect, the most prevalent used PKI certificates are SSL domain-name certificates (possibly representing 99.9999% of PKI certificate authentication operations that occur in the world today) ... and these certificates effectively are the CAs saying that they've checked with the domain name infrastructure (responsible for domain name ownership) and the domain name infrastructure corroporates the information as to who owns the domain name.

now what would you be suggesting with regard to CAs ...

1) if the domain name infrastructure could possible be wrong then should CAs stop manufacturing & issuing SSL domain-name certificates?

2) if the domain name infrastructure could possible be wrong, CAs should check with somebody else that knows nothing about domain name ownership instead?

3) if the domain name infrastructure could possible be wrong, CAs should totally cause all existing domain name infrastructures to be trashed and force everybody instead to register domain names with CAs instead (where the CAs would then directly control domain name ownership and wouldn't have to rely on some other agency that could possibly be wrong)?

My understanding of most of the CA business models is that they can manufactur a certificate that represents the binding of some information and that certificate could be trusted to the same level as if one was directly contacted the agency responsible for the vailidity of the information (that appears in the certificate; an agency that is rarely the CA itself). Other than that, I don't believe there is any fairy godmother that with a wave of the wand can change the trust level of the original information source because it appears in a certificate.

Most of the hyper about CA security & trust levels ... is that they want to be acceptable for certifying a broad range of different information that might exist at different trust levels. If they were to ever be involved in certifying some information that nominal has an extremely high native trust level ... they would prefer that the CA itself didn't represent the weakest point in the trust chain. However, I believe that many CAs may tout extremely high internal trust procedures ... that is significantly higher than the native trust of lots of information that they are certifying.

Similar to the method of compromising Caller-ID by "attacking" the origin that generates the Caller-ID ... it is possible to compromise a PKI system by attacking the source agency responsible for the information being certified (many such agencies may have significantly lower trust standards than the internal CA operation involved in manufacturing of the certificate).

--
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: Sun, 21 Oct 2001 20:10:06 GMT

Brian Inglis writes:
Always considered myself a member of the "Chuck Yeager" school of Tech. Support, and wanted to tell the PHBs where to go and what to do there, when after a crash, they all rushed into the machine room to "get someone to do something about it" -- we were already diagnosing the problem, and their wailing and gnashing of teeth rising over the roar of the A/C didn't make it any easier to think about the probable cause.

One particularly nasty series of crashes with no obvious cause resulted in many occurrences of ranting and raving by PHBs and a bunch of IBM CEs and CSRs on standby in the machine room for the next occurrence. It turned out some earlier moron^Wsys prog had dual allocated VM T-disk (temporary disk) space and page space to the same minidisk/partition, so the system crashed when a user ran an application that allocated temporary space and the system was paging system code!

attached cross-posting (at end) from a recent vm bug question

also ... somewhat akin to the chuck yeager school ref
https://www.garlic.com/~lynn/subboyd.html#boyd

with respect to I/O ... the 3274/3174 control units were particularly bad ... compared to the 3277/3272 which could provide subsecond response (if the sysetm could) ... it was nearly impossible to get real-subsecond (at the human interface screen/keyboard) response. The 3274/3174 tended to also have operational issues ... for extended periods of time we would see an average of 1 operator-initiated manual (BRS) reset per day. However, when we were doing all the I/O reliability stuff ... we stumbled across the fact that if you did a HDV/CLRIO instruction sequence in a tight loop to every control unit address ... the 3274/3174 would loose their mind and initiate reboot/reset on their own.

As we were to find out ... some number of hardware units exhibited that characteristic.

For the transition from 370 to 303x boxes ... one of the big changes was the channel director. The 370/158 had a hardware engine with two microprogram personalities ... one was the 370 instruction processor personality and the other was the channel I/O personality (the 158 hardware engine was responsible for executing both microprograms).

For the 303x line, they created a channel director that consisted only of a 158 engine with the channel I/O personality microprogram. The 303x processors were effectively

1) 3031 .. a 158 engine that only had the 370 micropogram personality (and a 2nd 158 engine as a channel director with the channel I/O microprogram personality). Old 158/3031/4341 national lab RAIN benchmark
https://www.garlic.com/~lynn/2000d.html#0 Is a VAX a mainframe?

2) 3032 ... a 168-3 engine that was reconfigured to use channel directors

3) 3033 ... a 168-3 "wiring" diagram that was remapped to newer chip technology. The newer chip technology was about 20% than the 168-3 technology but also had about ten times the circuits per chip. The 3033 originally was going to be a simple remapping only using the 1/10th circuit per chip and getting a 20% performance increase over the 168-3. Before product announce&ship, it was decided that the 3033 needed more like a 50% performance increase over the 168-3 ... which started a crash program to redo critical sections of the 168-3 core design to take advantage of the higher chip circuits (and performance advantage of doing more on-chip operations with fewer off-chip events).

In a manner similar to discovering the magic sequence to getting some of the control units to do a brain-wipe and reboot ... we found that it was possible to force the channel directors to perform a similar wipe/reset/reboot operation if you very quickly & in sequence did a CLRCH to all of the channel address for a director.

================== attachment

... basically over a course of a number of years ... I had the opportunity (at least three different times/instances) to totally eliminate all scenerios resulting in hung/zombie and/or the inverse which was a system crash because of faulty serialization

From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: re: LOGOFF/FORCE PENDING

Typically the problem is some outstanding i/o request that the kernel is apprehensive about.

Originally VM/370 had lots of "hung" (aka zombie) users as well as lots of timing failures.

For the Resource Manager ... I had to do 2000 benchmarks that took three months elapsed time to run to calibrate all the algorithms. To do the benchmarks I created an automated benchmark procedure (and created the original autolog command ... originally for automated benchmarking ... not originally for automated operations). The automated benchmark would 1) look at the next benchmark to run, 2) build the appropriate system, 3) reboot, 4) set the appropriate parameters, 5) autolog the appropriate simulated users with the appropriate simulated workload 6) wait for the prescribed amount of time 7) force off all the users, 8) save the benchmark data, 9) remove the current benchmark entry 10) loop back to "1".

When I originally started, every couple benchmarks would hang with a user not being able to be forced or crash the system.

In order to get the benchmarks done so I could get out the resource manager ... I totally redesigned the logoff/reset processing and created a new serialization infrastructure. One of the things the new mechanism would do would queue a serialization request, leave and then when it returned it would go looking for every pending I/O request belonging to this user. Whenever one was found, it would be re-assigned to the "system" userid. I had originally created the "system" userid in CP/67 for portions of pageable kernel (this was when I was at BCS). This was never shipped in IBM CP/67 product ... but was incorporated into the initial VM/370 release. This eliminated all cases of hung/zombie users and system crashes because of timing serialization problems. Basically the SYSTEM user was originally designed to be a place-holder for the virtual memory tables that the kernel was mapped into ... which was used to managed the non-fixed portion of the kernel.

The resource manager was eventually incorporated into the original HPO ...however, about 80% of the resource manager was retrofitted to the base (non-HPO product) ... leaving only about 20% of the resource manager in HPO (the resource manager also contained a lot of the structure rewrite that I had done for SMP ... and was required to distributed SMP support in the base product). Effectively, both the serialization rewrite and the SMP support from the resource manager was dropped into the base system leaving only about 20% of the resource manager to become HPO.

For a period of better than a year there was absolutely no cases of hung/zombie users and/or system crashes because of logoff/reset serialization problems.

The problem thru the years ... is that 1) some failure is diagnosed that might be thot to be a serialization problem ... and somebody creates an APAR that holds a user in suspension on the off-chance that will fix the problem (has happened every couple years which re-introduces the problem of hung/zombie users) or 2) somebody adds some new tweak for some sort of I/O so there is an outstanding request someplace that the serialization code can't find and can't re-assign to the "SYSTEM" user (i.e. doesn't update the serialization code to recognize the tweak to the I/O, again leading to serialization failure and/or hung/zombie user).

Later, I added the initial MIH ... as part of a generic rewrite of the I/O subsystem for the disk engineering lab so that they could run 6-12 test cells simultaneously in an operating system environment (at the time, MTBF for MVS was 15 minutes with just a single test cell active). This helped with hung devices ... i.e. a user could get suspended while waiting for a hung device ... but would not be "hung" in the sense that they would enter zombie state if forced/logoff/reset.

misc. SMP refs:
https://www.garlic.com/~lynn/subtopic.html#smp

misc resource manager refs:
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#wsclock

misc. disk test cell refs:
https://www.garlic.com/~lynn/subtopic.html#disk

--
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: Sun, 21 Oct 2001 20:23:10 GMT

Anne & Lynn Wheeler writes:
also ... somewhat akin to the chuck yeager school ref
https://www.garlic.com/~lynn/subboyd.html#boyd

for some OT, 40 second boyd (standing bet that he would allow anybody on his tail and in less than 40 seconds will have reversed the situation)
http://www.belisarius.com/modern_business_strategy/coram/catton.htm
https://web.archive.org/web/20010619224441/http://www.belisarius.com/modern_business_strategy/coram/catton.htm
http://www.belisarius.com/modern_business_strategy/coram/prologue1.htm
https://web.archive.org/web/20010617065342/http://www.belisarius.com/modern_business_strategy/coram/prologue1.htm

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

Processor Modes

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Processor Modes
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 22 Oct 2001 19:11:22 GMT

Paul Repacholi writes:
You got the last bit right anyway. But on the early ARPA net, a PDP-10 was 'standard issue' for quite some time. When did the first 360 arrive on the ARPA net?

With the original arpanet turn-on

I knew somebody that was hired as undergraduate at UCSB to do penetration study of arpanet before its initial turn-on (see extract from rfc208 attached).

misc. ref
https://www.garlic.com/~lynn/99.html#45

as previously mentioned ... the internal network (all mainframes) was larger (in terms of nodes) than the arpa/internet from just about the beginning up thru possibly 1985 (when the large number of workstations and PCs started to see a huge explosion in internet nodes).

index of RFCs can be found at:
https://www.garlic.com/~lynn/rfcietff.htm

random refs:
https://www.garlic.com/~lynn/internet.htm
https://www.garlic.com/~lynn/subindex.html#network
https://www.garlic.com/~lynn/subindex.html#network

various RFCs referencing UCSB 360/75
33, 101, 105, 115, 120, 138, 164, 208, 240, 252, 255, 266, 267, 287, 288, 293, 298, 302, 306, 311, 315, 319, 321, 326, 330, 332, 335, 342, 344, 353, 362, 366, 367, 370, 376, 477, 490, 494, 597, 599

various RFCs referencing UCLA 360/91
77, 90, 208, 240, 252, 255, 266, 267, 287, 288, 293, 298, 306, 307, 315, 319, 325, 326, 330, 332, 342, 344, 345, 353, 362, 366, 367, 370, 376, 392, 468, 490, 494, 597, 619

the "arpanet" as of 8/9/71 ... from RFC208


IMP       SITE        HOST                    NETWORK    SCHEDULED
NUMBER     NAME       NUMBER    HOST           ADDRESS   INSTALLATION
------     ----       ------    ----           -------   ------------
  1        UCLA         0       SIGMA-7              1
1       IBM 360/91          65
2        SRI          0       PDP-10 (NIC)         2
1       PDP-10 (Al)         66
  3        UCSB         0       IBM 360/75           3
4        UTAH         0       PDP-lO               4
  5        BBN          0       DDP-516              5  )   See Note 1
1       PDP-10 (A)          69  )
2       PDP-1O (B)         133
6        MIT          0       Honeywell 645        6
                        1       PDP-10              70
7        RAND         O       360/65               7
                        1       PDP-1O              71
8        SDC          O       IBM 360/75           8
9        HARVARD      O       PDP-1O               9
1       PDP-1               73
                        2       PDP-11             137
10        LINCOLN      O       IBM 360/67          10
                        1       TX2                 74
11        STANFORD     O       PDP-1O              11
12        ILLINOIS     O       PDP-11              12
13        CASE         O       PDP-1O              13
 14        CARNEGIE     O       PDP-1O              14
15        PAOLI        O       B6500               15
 16        NASA/AMES    O       IBM 360/67          16      8/3/71
2       TIP                144
17        MITRE        2       TIP                145      8/31/71
18        RADC         O       H 635/645           18      10/5/71
                        2       TIP                146
19        NBS          O       PDP-11              19      11/2/71
 20        ETAC         2       TIP                148      11/30/71
21        TINKER       O       418 III             21      1/4/71
22        McCLELLAN    O       418 III             22      2/1/72
23        USC          0       IBM 360/44          23      2/29/72
                        2       TIP                151
24        GWC          2       TIP                152      3/14/72
 25        NCAR         O       CDC 7600            25      3/28/72
2       TIP                153
30        BBN/TIP      2       TIP                158

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

Processor Modes

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Processor Modes
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 22 Oct 2001 19:41:00 GMT

Anne & Lynn Wheeler writes:
as previously mentioned ... the internal network (all mainframes) was larger (in terms of nodes) than the arpa/internet from just about the beginning up thru possibly 1985 (when the large number of workstations and PCs started to see a huge explosion in internet nodes).

index of RFCs can be found at:
https://www.garlic.com/~lynn/rfcietff.htm

random refs:
https://www.garlic.com/~lynn/internet.htm
https://www.garlic.com/~lynn/subindex.html#network

as prevsiously cited before, the other reason for the internal network being larger than the arpanet/internet up thru something 1985 ... was that effectively the primary internal network implementation effectively had gateway function implemented in every node. The ARPANET had a traditional state-of-the-art design requiring homogeneous networking thruout the whole infrastructure. The ARPANET didn't get real "internet" and "gateway" function until the great cut-over on 1/1/83 (homogeneous uniform network design and implementation is a huge imhibitor for extensive growth).

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

History

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: History
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 22 Oct 2001 19:53:18 GMT

Daniel.McLaughlin@COTTONSTATES.COM (McLaughlin, Daniel) writes:
Just a question...was VS/1 considered a part of the evolution of MVS? Or was that just the last leg of the MFT path?

effectively VS/1 ... mft in single 16mbyte virtual address space) and VS/2 ... aka svs, mvt in single 16mbyte virtual address apace.

MVS (multiple virtual storage ... or multiple virtual address spaces to distinguish between the original VS/2 SVS implementation, instead of having user programs all running in the same virtual address space shared with the kernel/nucleus ... MVS gave each user program its own address space ... although it maintained the SVS/MVT design point with the kernel resident in the application address space. In some sense, from the application standpoint it was as if it was still SVS but with no other applications running (or even MVT with no other applications running).

I have vague recollections of Ludlow having cobbeled together MVT with "CCWTRANS" from cp/67 (module that performed the page-fixing and virtual->real translation for CCWs) for initial pass at SVS.

--
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, 23 Oct 2001 14:19:38 GMT

"Phil Weldon" writes:
No thirty-year-old mainframe is worth the maintenance cost.

hil Weldon, pweldon@mindspring.com

no 30 year-old mainframe is worth the cooling costs

no 30 year-old mainframe is worth the water costs for the cooling

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

is this correct ? OS/360 became MVS and MVS >> OS/390

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: is this correct ? OS/360 became MVS and MVS >> OS/390
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 23 Oct 2001 17:31:18 GMT

john_g123_5@yahoo.com (john) writes:
OS/360 became MVS, MVS is becoming OS/390

OS/360 became PCP ... and then PCP and MFT ... and then PCP, MFT, and MVT.

MVT became VS2(aka SVS), MFT became VS1 ...

VS2/SVS became MVS.

In any case, os/360 became multiple things ... one of which is evolving into os/390.

random ref:
https://www.garlic.com/~lynn/2001l.html#36 History

posted yesterday in this same newsgroup on the very same subject

misc. reference:
https://www.garlic.com/~lynn/2001k.html#75 Disappointed
https://www.garlic.com/~lynn/2001l.html#0 Disappointed
https://www.garlic.com/~lynn/2001l.html#16 Disappointed

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

is this correct ? OS/360 became MVS and MVS >> OS/390

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: is this correct ? OS/360 became MVS and MVS >> OS/390
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 23 Oct 2001 19:24:08 GMT

Allodoxaphobia writes:
and then MFT-II ----------------------- remember that?

I never did a MFT-II install. I used os/360 R6 PCP on 360/30 (starting summer of '66, i would get 48hrs straight dedicated time ... that they allowed me to use uninterrupted along with the privilege of going w/o sleep)

I did sysgens & support for R9.5 MFT, R11 MFT, R14 MFT, R15/16 MVT, R18 MVT, etc. The university never used MFT-II (there have recent postings here regarding the kernel requirements differences for MFT-II and MVT).

I vaguely remember MVT showing up in R12 or R13 (I worked with some people that installed R13 MVT) but it was still quite buggy and we waited until R15/16 to do an MVT install.

R15/16 (as mentioned before) also introduced being able to specify VTOC position. Since R11, I had been doing hand-built stage-II sysgens ... so that data sets & PDS members were carefully organized for optimal arm seek performance (for specific univ. workload getting 60+ percent reduction in elapsed time).

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

MVS History (all parts)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MVS History (all parts)
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 23 Oct 2001 23:47:32 GMT

IBM-MAIN@ISHAM-RESEARCH.COM (Phil Payne) writes:
Yes, long before. I've never seen any documentary proof, but I believe that at some point IBM developers must have been told in very strong terms to get rid of the SEARCH ID/TIC sequences in channel programmes. This was around the time block multiplexing was maturing and dynamic reconnect was on the horizon - it's always seemed to me as if IBM regarded these aspects of I/O as the most pressing performance problem in the late 1970s through to the early 1990s. Every major OS user of high channel load programmes had some major improvement (usually complete replacement) during this period - ISAM, CVOLs, VTOCs, etc.

the whole multi-record (& multi-trach) search paradigm was a resource trade-off from the early 60s regarding very limited real storage and (by comparison) huge excessive channel capacity.

at least by the mid to late 70s ... the relative trade-off of storage resources and channel resources had totally flipped.

the following is type of comparison that i started publishing in late '70s.
https://www.garlic.com/~lynn/93.html#31 bit i/o or kicking the mainframe out the door


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

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

the above data was VM specific ... in part, not having the same level of detailed data for 15 year comparison running the same workload with regard to mvt & svs/mvs. However, in the late '70s I had "shot" some severe performance problems at large mult-cec SVS shared-disk installations that turned out to be all caused by multi-track PDS searches. Also have some stories of VM/MVS shared disk installations where operations strickly forbid placing "any" MVS pack on a "CMS string" because there were immediate, observable factor of up to ten times degradation in CMS interactive response when there was any MVS pack on a string nominally devoted exlusive to CMS (one could make some observations about TSO response already being normally so bad that it was not possible to observe the additional severe degradation that MVS multi-track I/O sequences had on TSO response).

In any case, the above comparisons i.e. disk & channel thruput had degraded by a factor of ten times relative to overall system thruput (aka other system resources got 50 times more plentiful while disk & channel resources only got five times more plentiful ... so there was a relative disk & channel system thruput decline of a factor of tnn times) ... prompted GPD to assign the whole disk performance group to rebutting the data.

After a couple months ... they came back with a report that the obove data was actually optimistic ... if you take into account detailed data about RPS-miss, the relative disk & channel thruput had declined by more than a factor of ten times. The analysis was turned into a GUIDE presentation ... focusing on all the "positive" configuration things that an installation should do (not actually coming out and stating that relative disk & channel i/o thruput/resources had declined by better than a factor of ten times over a period of 15 years).

At the time, there was a proposal for providing MVS support for a non-CKD environment (i.e. eliminating all multi-record and multi-track searches). The nominal explanation would be to allow MVS to run in an all FBA environment ... but it would have also had the result that it could also operate in a CKD environment w/o all the enormous requirements for channel, controller, string & drive resources. Even if all the code was fully developed, integrated, & tested when turned over to the responsible group there still was a prohibitedly enormous $$ estimated associated with actually getting it into the field.

--
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: Wed, 24 Oct 2001 00:02:24 GMT

Brian Inglis writes:
To tune, enable seek monitoring, feed the directory or mdiskmap to V[M]MAP to map the busy areas on drives in symbolic fashion, then shuffle areas until you level the I/O across the drives, paths and channels, reduce the total seek lengths on the system and the long seeks to low probability, have at most one warm area in the sweet spot on each drive, or one hot spot per channel, with less than 30% busy per drive/channel?

there was another analysis that came in regarding upgrading from 3350s to 3380s. It showed that to have the relative same access performance per unit of data ... you weren't allowed to completely allocate a 3380 from 3350 data (from a fully load-balanced 3350 configuration). The issue of course is that the total amount of data that could be allocated on a 3380 was significantly larger than the relative performance increase of a 3380 compared to a 3350.

Because of frequent inability of administrators to deal with the concept, there was a serious proposal to offer a "high-performance" 3380 that cost more than a normal 3380 ... which consisted solely of a micro-program load that resitricted the number of cylinders that could be accessed on the drive (which was otherwise a normal 3380).

Basically if you allocated more than 80 percent of a 3380 ... there was a overall system degradation compared to an all 3350 installation. It was possible to show that the price per bit even at 80 percent allocation was less than 3350. It was also possible to show that overal system performance degradation cost more (i.e. you take a percentage of the total system costs of all components, processors, disks, channels, memory, etc ... you didn't even have to take into account the cost of lost user time) was significantly larger than any cost savings from needing fewer 3380 drives when allocated at 100 percent full.

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

is this correct ? OS/360 became MVS and MVS >> OS/390

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: is this correct ? OS/360 became MVS and MVS >> OS/390
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 24 Oct 2001 13:31:11 GMT

Peter Flass writes:
Not really, AFAIR. OS/360 was introduced in three flavors: PCP (primary control program), MFT (multiprogramming with a fixed number of tasks, and MVT (multiprogramming with a variable number of tasks). All three were in use simultaneously. I don't know what features PCP had, but it was a stripped-down system. Users chose one of the other two based on machine size and their requirements. When VS came in MFT became OS/VS1 and MVT became OS/VS2, basically with virtual storage layered on top of each system's feature set.

in the attached, it has "68-??" for MFT & "67-12" for MVT ... but MFT was available at least by R9.5 when I did sysgen for it ... and MVT was either R12 or R13.

from
https://web.archive.org/web/20010218005108/http://www.isham-research.freeserve.co.uk/chrono.txt


+ IBM OS/360        64-04 6????     PCP - SINGLE PARTITION SCP FOR S/360
IBM S/360-30      64-04 65-05 13  SMALL; 64K MEMORY LIMIT, MICROCODE CTL.
  IBM S/360-40      64-04 65-04 12  SMALL-INTERMED.; 256K MEMORY LIMIT
IBM S/360-50      64-04 65-08 16  INTERMED.-LARGE
IBM S/360-60      64-04  N/A      LARGE - NEVER SHIPPED
IBM S/360-62      64-04  N/A      LARGE - NEVER SHIPPED
  IBM S/360-70      64-04  N/A      LARGE - NEVER SHIPPED
IBM S/360-92      64-08           VERY LARGE SCIENTIFIC S/360
  IBM S/360-91      64-11 67-10     REPLACES 360/92
CDC 6800          64-12           LARGE SCIENTIFIC SYSTEM - LATER 7600
+ IBM OS/360        65-?? 68-??     MFT - FIRST MULTIPROGRAMMED VERSION OF OS
IBM 2314          65-?? 65-04     DISK: 29MB/DRIVE, 4DR/BOX REMOV. MEDIA $890/MB
  IBM S/360-65      65-04 65-11 07  MAJOR LARGE S/360 CPU
IBM S/360-75      65-04 66-01 09  LARGE CPU; NO MICROCODE; NOT SUCCESSFUL
  IBM S/360-95      65-07 68-02     THIN FILM MEMORY - /91, /92 NOW RENAMED /91
IBM S/360-44      65-08 66-07 11  INTERMED. CPU,;SCIENTIFIC;NO MICROCODE
IBM S/360-67      65-08 66-06 10  MOD 65+DAT; 1ST IBM VIRTUAL MEMORY
IBM PL/I LANG.    66-?? 6????     MAJOR NEW LANGUAGE (IBM)
  IBM S/360-91      66-01 67-11 22  VERY LARGE CPU; PIPELINED
IBM PRICE         67-?? 67???     PRICE INCREASE???
+ IBM OS/360        67-?? 67-12     MVT - ADVANCED MULTIPROGRAMMED OS
IBM TSS           67??? ??-??     32-BIT VS SCP-MOD 67; COMMERCIAL FAILURE

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

QTAM (was: MVS History)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: QTAM (was: MVS History)
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 24 Oct 2001 15:00:50 GMT

dba@duda.com (David Andrews) writes:
Any greybeards that can give us a brief overview of QTAM?

I vaguely remember that PL/I (F) had language support for QTAM files, and that it looked pretty easy to use from the applications coder's point of view. Sure, there were still device dependencies to deal with, but getting data up and down the wire looked easy.

And wasn't there a queueing mechanism? (The "Q" in "QTAM".)

Why was QTAM a failure? Performance issues? What did TCAM do that QTAM didn't... and vice-versa?

most of the stuff that I was aware of was BTAM. I worked on library project at the university ... we were one of the beta-test sites for the original CICS. For various & sundry reasons ... I think that there was lots more BTAM use than QTAM (not the least of which was that QTAM was a lot more complex and had a lot more bugs ... and constant stream of QTAM PTFs).

when I did the original tty/ascii support for cp/67, i started out borrowing translate table from BTAM ... but quickly made some number of modifications to it.

The base CP/67 support had dynamic terminal type recognition ... as long as it was the same SAD (line scanner) on the 2702. When I put in the tty/ascii support for CP/67, I modified the base support to do dynamic terminal type recognition across line scanners ... playing around with the 2702 SAD command to switch line-scanners.

In testing it worked ... but one of the IBM engineers eventually got around to telling me that while the 2702 supported dynamic switching of the line-scanner ... that the 2702 implementation took some sort cuts and hardwired the oscillator to each line ... so while it was possible to dynamically switch between 2741 line-scanner & TTY line-scanner on a per line basis ... it didn't officially work since the 2741 & TTY were different baud rates with corresponding different oscillator.

This was the genesis of the ibm PCM controller business (2702 wouldn't let me do dynamic terminal & line-speed). After going thru the details ... we started a replacement telecom controller project where we built our own terminal controller, originally based on an Interdata/3, reversed engineered the multiplexor channel protocol and built our own channel attach board. In the interdata/3 "line-scanners", we built in both dynamic terminal & line speed recognition.

random refs:
https://www.garlic.com/~lynn/submain.html#360pcm

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

QTAM (was: MVS History)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: QTAM (was: MVS History)
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 24 Oct 2001 17:06:01 GMT

jraben@cascinc.com (Jeff Raben) writes:
As far as "speed/protocol" recognition: if you "knew" what you were on and typed a specific character while on 2702 (I started on that) or 2703(even 2701) and the Memorex 1270 (the 1270 could even change speeds) (by the way- SAD went bye-bye and was treated as a NOP as on some configurations the SAD command had to match the pluging - os if the plugs were set who needs SAD)

1270 post-dated all our work ... i.e. our interdata/3-based was the first pcm controller and one of the primary reasons the project started was the inability of the standard ibm controllers to support dynamic terminal/speed recognition. I don't know what processor the 1270 used as a basis (but there were a number of businesses that got into the business emulating the work that we had originally done) ... but the interdata/3-based thing that we did ... eventually over the years evolved into a perkin/elmer product (i.e. p/e at some point bought interdata). A couple years ago (effectively 30 years after we had put together the original box) we were touring a machine room of a company doing a huge amount of transaction processing and they still had perkin/elmer box handling a large amount of the traffic.

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

Processor Modes

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Processor Modes
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 24 Oct 2001 17:18:13 GMT

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

MVS History (all parts)

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MVS History (all parts)
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 24 Oct 2001 17:46:27 GMT

Anne & Lynn Wheeler writes:
After a couple months ... they came back with a report that the obove data was actually optimistic ... if you take into account detailed data about RPS-miss, the relative disk & channel thruput had declined by more than a factor of ten times. The analysis was turned into a GUIDE presentation ... focusing on all the "positive" configuration things that an installation should do (not actually coming out and stating that relative disk & channel i/o thruput/resources had declined by better than a factor of ten times over a period of 15 years).

Preface from paper by member of performance group... also delivered at Share in Aug. of '84
This review makes liberal use of the computer science literature. As usual, the views expressed in this report are those of the author. Many contributed facts and ideas, but the selection and presentation are the author's responsibility, including any mistakes. I am especially indebted to Lynn Wheeler for pointing out how the relative speeds of things have changed over the years, to Brian J. Smith for helping me through many of the intricacies of attachment modeling, to Bill O'Brien for suggesting this review, and to my manager, Steve Goldstein, for his patient support throughout these activities.

Summary from the paper
DASD subsystems have been crucial to the success of time-sharing systems for over twenty years. Hardware has evolved and components get bigger and faster at differing rates. Faster CPUs are now available with parallel processing capabilities that exceed the traditional notions of IO requirements. Bigger external storage as well as larger and faster memories are coming on line that will require even more effective storage and performance management. If the full system potentials are to be realized, the effectiveness of the user IO is going to have to be improved.

Configuration of DASD subsystems for availability and performance is accomplished by using many dedicated channel paths and keeping strings short. The requirement for high path availability to an arm to support good response leads to the less than 25% busy channel guidelines, etc. Where this is too expensive or impractical for space, cost, or configuration reasons, compromises must be made. DASD capabilities, quantified by reliability, throughput, response time and cost, can make an application successful or unsuccessful. Equally important are the effects of the application environment. An understanding of this environment as well as the DASD parameters usually is required for successful application management. An extensive data base cataloging the systems past performance, coupled with a calibrated model provides what is effectively an expert or knowledge based system for exploring these compromises.

Storage management, the system centered management of capacity and performance, is required to deal with the complexities of active and inactive data. Because of the large number of DASD and connections involved, the effects also are difficult to simulate and measure precisely. More attention to the IO subsystem, in particular, the user data base IO, is required to realize the potential of current and future technologies.

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

five-nines

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: five-nines
Newsgroups: bit.listserv.ibm-main
Date: Thu, 25 Oct 2001 00:55:46 GMT

computerguy@ANTELECOM.NET (Dino Jr) writes:
The following quote is from Byte:

http://www.byte.com/documents/s=364/byt20000510s0011/

"... IBM offers mainframe systems with System/390 that are designed for five nines (99.999 percent) reliability in certain configurations. Five nines amounts to 5.25 minutes of downtime a year. This is a significant accomplishment, requiring redundant hardware and specific software. Don't expect your PCs to ever reach this level."

talking to guy responsible for one of the large financial networks a couple years ago ... he credited 100 percent availability for the previous six years to
1) IMS hot-standby
2) automated operator

aka ... as hardware has gotten more & more reliable ... human/operator mistakes are representing a larger percentage of application outages

https://www.garlic.com/~lynn/subtopic.html#hacmp

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

redhat 7.2 & gnome/nautilus

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: redhat 7.2 & gnome/nautilus
Newsgroups: linux.redhat
Date: Thu, 25 Oct 2001 01:05:52 GMT

i got rh7.2 boxed set today direct from rh and did an upgrade on a rh7.0 installation.

everything seems to be working ... except gnome/nautilus window manager seems significantly more sluggish compared to rh7.0

machine is dual 1ghz processers with 1gbyte of memory

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

Virus propagation risks

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Virus propagation risks
Newsgroups: comp.mail.eudora.ms-windows
Date: Thu, 25 Oct 2001 15:39:52 GMT

"Stephane Hebert" writes:
Hi folks,

As most of us know, OE is an easy way of propagating some viruses thru the Adress Book. How does Eudora stand in this area ? How "safe" is it virus wise ?

I know that if I open an attachement that contains a virus, then Eudora isn't to blame. I'm talking about ways that malicious code could take advantage of Eudora to propagate itself or to infect a local machine. What are the risks compared to OE ?

various network-related products with scripting capability have huge vulnerabilities. we noticed this about 1974 (yes >25 odd years ago) and put out a notice on the subject.

at the 1996 developers conf. (in moscone) every session started, ended and was riddled with we are going to preserve your (vs/basic) investment (aka internet was a momentary aberration but vs/basic & scripting is here to stay).

prior to that the major vulnderability (possibly 90+ percent) was buffer overruns (primarily an artifact of C language usage) but things have significantly change since that time.

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

What makes a mainframe?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What makes a mainframe?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Thu, 25 Oct 2001 21:48:25 GMT

mkothari@DATAMIRROR.COM (Manish Kothari) writes:
So how come there are so many UNIX boxes out there?

in the late '70s work was done on making UNIX a portable operating system that could run on a number of different architectures/platforms. In the early '80s a number of companies started building computers ... workstations, minis, supercomputers, etc ... with relatively reduced hardware components.

If these operations were to address the operating system by traditional mechanism of building a proprietary operating system from scratch ... it would of totally blown the whole economic equation out of the water.

They needed software & operating system that represented an economic outlay that was less or comparible to the hardware development expenditure. At the time, Unix fit the bill ... the basic operating system cost was relatively nominal and the development expense to port to whatever hardware platfrom they were building was also relatively inexpensive (aka the software costs didn't totally dominate the cost of the whole operation by several orders of magnitude).

some of the technical workstations are an example
https://www.garlic.com/~lynn/96.html#4a

the 801 displaywriter follow-on project (that got killed) tried to save itself in a similar fashion
https://www.garlic.com/~lynn/2000d.html#60 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
https://www.garlic.com/~lynn/2000d.html#65 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
https://www.garlic.com/~lynn/2001f.html#22 Early AIX including AIX/370
https://www.garlic.com/~lynn/2001f.html#43 Golden Era of Compilers

random other observations from the early '80s
https://www.garlic.com/~lynn/2001l.html#25

Also, during the '70s a lot of universities had installed and trained people on Unix (a lot less expensive than traditional dataprocessing platforms). A lot of these were engineering graduates which were becoming major players in various of these new computer operations in the '80s.

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

Security standards for banks and other institution

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security standards for banks and other institution
Newsgroups: sci.crypt
Date: Fri, 26 Oct 2001 14:18:31 GMT

Marco Fioretti writes:
This is at the application level, right? It means that if a financial institution encrypts data end to end with (for example) 64 bits DES key, it is OK (as far as the standard is concerned) to transmit the encrypted bits on an unsecure channel, or not?

Also, is the X9 standard mandatory only in US, or used abroad too?

X9 is the financial industry accredited standards body for ANS/ANSI (i.e. US). TC68 is the financial industry accredited standrads body for ISO (i.e. international). US is nominal the chairman of the TC68 body (and the X9 secretariat is also the TC68 secretariat).

Frequently standards from X9 (and/or other countries) are forwarded to ISO. In the past that was required almost a complete reset of the standards process. There is work on streamlining the process involving standards at the ISO level forwarded from country standards organization. Frequently X9 standards become ISO standards.

Within the payment card industry the standard is ISO8583 for messages flowing between terminals/merchants and nearly all other points (used by both debit and credit payment card implementations).

the X9 website is
http://www.x9.org/

the TC68 website are:
http://www.tc68.org/
http://www.iso.ch/iso/en/stdsdevelopment/tclist/TechnicalCommitteeDetailPage.TechnicalCommitteeDetail?TC=68

There are variety of standards that cover different aspects.

For instance, X9.59 is a standard for all account-based retail transactions ("ALL" as in internet, non-internet, point-of-sale, credit, debit, ACH, etc). The requirement given the X9A10 working group for X9.59 was that it preserve the integrity of the financial infrastructure without requiring encryption (only authentication) ... i.e. the integrity of the financial industry would still be preserved if the transaction wasn't encrypted and also happened to be transmitted over any kind of channel.

misc. X9.59 references
https://www.garlic.com/~lynn/

A NACHA/debit pilot reference:
https://web.archive.org/web/20020204041928/http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm

Within X9, X9F is the committee that is responsible for encryption and security standards. X9.59 was done under the X9A committee somewhat more as an end-to-end business integrity standard rather than a strictly security or encryption standard (including the specific requirement that the financial industry integrity would be preserved without requiring encryption).

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

Security standards for banks and other institution

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Security standards for banks and other institution
Newsgroups: sci.crypt
Date: Fri, 26 Oct 2001 21:09:18 GMT

Anne & Lynn Wheeler writes:
Frequently standards from X9 (and/or other countries) are forwarded to ISO. In the past that was required almost a complete reset of the standards process. There is work on streamlining the process involving standards at the ISO level forwarded from country standards organization. Frequently X9 standards become ISO standards.

I believe that NIST has also made some statement about streamlining FIPS standards process ... being able to directly accept X9 standards.

One of the issues where X9 standards can come into play is regarding legal disputes where whether or not X9 standards were observed can change the burden and/or amount of proof. In that sense, observation of X9 standards might be considered a conservative liability mitigation policy.

--
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: alt.folklore.computers,bit.listserv.ibm-main
Date: Sat, 27 Oct 2001 15:31:50 GMT

Brian Inglis writes:
Controller cache helped, especially if it supported non-volatile memory for delayed write back with fast completion (write to NVM, say done, write later when passing thru the neighbourhood anyway or doing nothing else). Controller cache also surfaced bugs when drivers made assumptions that they would have time to finish up their processing before they got the completion interrupt.

anybody remember 3880-13/3880-23 names?

aka


Corinth    2305-1
Zeus       2305-2
2311
2314
Merlin     3330-1
Iceberg    3330-11
Winchester 3340-35
           3340-70
3344       (3350 physical drive simulating multiple 3340)
?Piccolo   3310       FBA
Madrid     3350
NFP        3370       FBA
Florence   3375       3370 supporting CKD
Coronado   3380 A04, AA4, B04
EvergreenD 3380 AD4, BD4
EvergreenE 3380 AE4, BE4



Cutter     3880
Ironwood   3880-11    (page block cache)
??         3880-13    (full track cache)
Sahara     3880-21    (larger cache for "11")
??         3880-23    (larger cache for "13")

does anybody remember 1655?

some old 3880-11/3880-13 posts
https://www.garlic.com/~lynn/2000d.html#13 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2001.html#18 Disk caching and file systems. Disk history...people forget
https://www.garlic.com/~lynn/2001b.html#61 Disks size growing while disk count shrinking = bad performance
https://www.garlic.com/~lynn/2001c.html#17 database (or b-tree) page sizes
https://www.garlic.com/~lynn/2001d.html#49 VTOC position
https://www.garlic.com/~lynn/2001d.html#68 I/O contention

--
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,bit.listserv.ibm-main
Date: Sat, 27 Oct 2001 17:14:13 GMT

Steve Samson writes:
Anne/Lynn,

The 3880-13 was Sheriff. Also the 3850 MSS was known successively as Cybernet, Comanche, and Oak.

Steve


   Cybernet   3850       MSS (also Comanche & Oak)

   Cutter     3880
Ironwood   3880-11    (page block 8mbyte cache)
Sheriff    3880-13    (full track 8mbyte cache)
Sahara     3880-21    (larger cache for "11")
   ??         3880-23    (larger cache for "13")

one of the "problems" with the cutter caches was that there was just a single "exposure" per drive ... as a result, requests for data that happened to be in the cache would get queued behind requests that had to go to the physical device (I had tried previously to get multi-exposures for madrid/3350 as mechanism of having multiple queued requests in the hardware).

When 3880-13 was originally announced ... it claimed 90% hit rate ... the benchmark example was sequential read of 4k blocks (10 blocks per track). The first read for a block (on a track) would be a miss ... but would bring in the rest of the track ... and then the remaining 9 block reads would all be "hits" ... resulting in 90% cache hit ratio.

--
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: alt.folklore.computers,bit.listserv.ibm-main
Date: Mon, 29 Oct 2001 15:47:37 GMT

Anne & Lynn Wheeler writes:
When 3880-13 was originally announced ... it claimed 90% hit rate ... the benchmark example was sequential read of 4k blocks (10 blocks per track). The first read for a block (on a track) would be a miss ... but would bring in the rest of the track ... and then the remaining 9 block reads would all be "hits" ... resulting in 90% cache hit ratio.

i.e. a little twiddling with the sam/access-method parameters to sequentially read effectively full-track worth of records per buffer and double/triple buffering ... would

1) reduce elapsed time
2) reduce excp
3) reduce processing overhead

basically disk cache only addressed #1.

as at the time of 11/13 ... 8mbytes was comparable or smaller than real-memory sizes. in the late '70s we did a lot of detailed record access tracing of a number of different live loads. that was run thru a fairly detailed model of different kinds of caches (device, controller, channel, director, i/o subsystem, system). Except for pathelogical cases of misbehaving accesses, global caches alwas came out better. This was something we already knew from the work in the 60s on local and global page replacement algorithms. the work also develped a methodology for efficient, near-real time trace reductions that could be used in conjunction with dynamic disk data re-organization.

the other work, initially for 3880-d11 was dup/no-dup management strategy. "dup" assumes that record could reside both in main storage and "d11" at the same time (i.e. normal cache read). with main storage as large or larger than cache ... there was high probability that nearly all records in the d11 cache were duplicates of what was in main storage. The "no-dup" management always did a d11 "distructive" read but normal writes i.e. nearly guaranteed that there was almost no duplicates in d11 cache. Then there was a little code that could dynamically switch between dup & no-dup based on configuration, system activity, and cache hit rate statistics.

The problem, of course, is in a high-dup scenerio, there is nearly zero cache hit ... since nearly every record is duplicated in real storage and therefor is never going to be requested. The effect is that effectively the total number of records in some electronic storage is equal to the number of records of main storage. Going to no-dup management, means that space is freed up in cache for every page that is in real storage ... and therefor in a no-dup management scenerio, the total number of records in some electronic storage is equal to the number of records in main storage plus the number of records in the cache(s). Effectively the way that (d11) cache is populated in the no-dup scenerio is when it is replaced in real memory and has to be written back to disk (no-dup requires more i/o overhead since it has to force writes on replaced records even when they haven't been changed).

Basically in the cache envirionment with high-dup rates, the no-dup strategy trades off cache-hit ratio against extra i/o (write) activity.

misc. local/global discussions
https://www.garlic.com/~lynn/94.html#1 Multitasking question
https://www.garlic.com/~lynn/96.html#0a Cache
https://www.garlic.com/~lynn/96.html#0b Hypothetical performance question
https://www.garlic.com/~lynn/99.html#18 Old Computers
https://www.garlic.com/~lynn/2000.html#78 Mainframe operating systems
https://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2000f.html#36 Optimal replacement Algorithm

misc. i/o cache discussions
https://www.garlic.com/~lynn/94.html#9 talk to your I/O cache
https://www.garlic.com/~lynn/94.html#13 talk to your I/O cache
https://www.garlic.com/~lynn/2001b.html#61 Disks size growing while disk count shrinking = bad performance
https://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2001i.html#42 Question re: Size of Swap File

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

hammer

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: hammer
Newsgroups: comp.arch
Date: Mon, 29 Oct 2001 16:46:31 GMT

Bernd Paysan writes:
Predictions into the long-term future are always bogus. That's why they are predictions. Statistics prove that there is no better way to predict the future of a company than assuming that the chance it will be around in n years is about 50% when the company exists already n years. That's long-term. For short-term analyses, there are better ways to go. But there is no realistic short-term threat to AMD going out of business.

there is analogy to black-holes ... i.e. they are massive (possibly either in time or size dimensions) and they evaporate. it wasn't a very good corrolary until i heard about the evaporation part. massiveness can imply difficulty with adaption (although massiveness isn't the only factor) organisms can become extinct if the environment for their adaptation changes; some organisms may only exist because they have some adaption to a specific economic niche and if that changes ... they deserve to go away.

another example of predictions and statistics involves chaos and non-linearities. the hedge-fund industry was going along great guns until they hit a discontinuity a couple years ago and facing an immediate $3b short-fall ... the fed had to step-in and request that ten of the coutry's largest financial institutions donate to cover the short-fall (aka bail-out).

random ref:
https://www.garlic.com/~lynn/2001f.html#35 Security Concerns in the Financial Services Industry
https://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information security
https://www.garlic.com/~lynn/aepay3.htm#riskaads AADS & RISK Management, and Information Security Risk Management (ISRM)

--
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: bit.listserv.ibm-main,alt.folklore.computers
Date: Mon, 29 Oct 2001 18:49:22 GMT

b19141@ACHILLES.CTD.ANL.GOV (Barry Finkel) writes:
Winchester 2314
Zeus Athens 2305-1
Zeus Corinth 2305-2

misc. ref (see under 1973):
http://www.storage.ibm.com/hdd/firsts/1970.htm
https://web.archive.org/web/20010810145013/http://www.storage.ibm.com/hdd/firsts/1970.htm

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

hammer

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: hammer
Newsgroups: comp.arch
Date: Mon, 29 Oct 2001 20:55:41 GMT

Anne & Lynn Wheeler writes:
another example of predictions and statistics involves chaos and non-linearities. the hedge-fund industry was going along great guns until they hit a discontinuity a couple years ago and facing an immediate $3b short-fall ... the fed had to step-in and request that ten of the coutry's largest financial institutions donate to cover the short-fall (aka bail-out).

& of course my favorite chaos, agility and business ref:
https://www.garlic.com/~lynn/subboyd.html#boyd
http://www.belisarius.com/
https://web.archive.org/web/20010722050327/http://www.belisarius.com/

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

Windows XP on quad DPS 8/70M?

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

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Windows XP on quad DPS 8/70M?
Newsgroups: alt.os.multics
Date: Tue, 30 Oct 2001 02:29:15 GMT

"Mxsmanic" writes:
The interesting thing is that, even with all this fancy processing, it takes about the same time to do something productive on a PC as it did on a timesharing system like Multics. I'm not any faster at writing newsgroup posts or e-mail now with a fancy Windows system in front of me than I was twenty years ago with just a terminal in front of me. I guess it does look a lot prettier on the screen, I have to admit that. It scares me each time I think about the incredible amounts of horsepower that are being chucked out the window to draw pictures with inefficient code, however. Think what could be done if that horsepower were put to the most efficient use possible!

do you think of people who were used to only trains ever thot the same about personal automobiles (compared to personal pcs) ... not only huge amounts of horsepower to cart a single person from here to there frequently on trips that have no productive purpose ... but also horsepower that probably sat around idle not doing anything >90 percent of the time.

--
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: Tue, 30 Oct 2001 17:01:12 GMT

hifan@gmx.de (Florian Lindauer) writes:
I am currently writing a small article, where also RSA's SecurID-product is mentioned. So I am trying to get some info on it. I would have taken for granted, that the system works with public key cryptography - after all RSA is the inventor of the probably most famous algo in this field.

security dynamics had securid long before they bought RSA.

misc
http://www.inet-one.com/cypherpunks/dir.96.04.11-96.04.17/msg00525.html

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

MVS History (all parts)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MVS History (all parts)
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 30 Oct 2001 18:15:55 GMT

Anne & Lynn Wheeler writes:


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*

i.e.
https://www.garlic.com/~lynn/2001l.html#40

here is survey from summer of 1981 ... just slightly before above HPO/3081k time-frame and ten years after the 3.1L numbers.


Name            CPU     MIPS    Memory  Disk    Total  Concurrent
                                megs    megs
3.1l            360/67  .3      .75     1200    ?       80
CMUA            KL10    2.0     4.0     1600    1175    80
SAIL            KL10(2) 3.6     10      1600    230     70

==================================================================
CMU
Name            CPU     Mips    Memory  Disk    Total   Concurrent
                                (megs)  (megs)  Users   Users
CMUB            KA10    0.5     1.0      320    225     18
CMUA            KL10    2.0     4.0     1600    1175    80
CMUC            KL20    2.0     6.0     1000    160     24
IUS             11/780  1.1     4.0     1075    70      16
VLSI            11/780  1.1     4.0      600    55      12
CAD             11/780  1.1     4.0      460    60      15
ZOG             11/780  1.1     4.0      600    85      12
PS              11/780  1.1     4.0      300    50      10
GP              11/780  1.1     4.0      600    320     20
CFS             11/750  0.7     2.0      675    0       0
IS              11/750  0.7     2.0      675    ?       ?
Robot-1         11/750  0.7     2.0      675    ?       ?
Robot-2         11/750  0.7     2.0      675    ?       ?
Robot-3         11/750  0.7     2.0      675    ?       ?
Robot-ME        11/750  0.7     2.0      675    ?       ?
ELAB            11/750  0.7     2.0      675    ?       ?
Robot-11        11/40   0.4     0.25     200    75      12
(17)            Alto    0.3/5.1 0.2 5    3/51   250     13
(22)            Perq    1.0/22  0.25     24/528 50      16

==================================================================
Bell Labs
Name             CPU     Mips    Memory  Disk   Total   Concurrent
                                (megs)  (megs)  Users   Users
Alice           11/780  1.1     4.0     750     309     25
Ikeya           11/750  0.7     1.0     320      35      5
Enrke           11/750  0.7     1.0     320      35      5
Seki            11/750  0.7     2.0     320      35      5
Forbes          11/750  0.7     2.0     320      35      5
Swift           11/750  0.7     2.0     320      35      5
R70             11/70   1.1     1.6     920     244     25
FS              11/45   0.5     0.2     200     209     10

====================================================================
LBL
CPU     Mips    Memory  Ports   Total   Concurrent
                (megs)  (megs)          Userids Users
7600    10                              batch
6600    2.5                             batch
6400    2.0                             batch
11/70   1.1     ?       ?       ?       ?
11/70   1.1     ?       ?       ?       ?
11/780  1.1     2       40      214     15
11/780  1.1     4       32      50      12
11/780  1.1     4       32      50      20
11/780  1.1     4       32      50      20
11/780  1.1     4       32      50      20
11/780  1.1     4       32      86      15
4331    0.25    ?       ?       ?       ?

==================================================================
Stanford
Name            CPU     Mips    Memory  Disk    Total   Concurrent
                                (megs)  (megs)  Users   Users
SAIL            KL10(2) 3.6     10      1600    230     70
SCORE           20/60   2.0     4       400     230     55
VAX1            11/780  1.1     4       400     ?       small
VAX2            11/780  1.1     2       200     ?       small
IBM             4331    0.5     4       8-3310s 30      8
(16)            Alto    0.3/4.8 0.25/4  2/32    16      16

==================================================================
MIT
                CPU             Mips            Concurrent Users
                KA 10 (3)       0.5 (1.5)       30
                20/60           2.0             45
                KL 10           1.0             24
                11/780          1.1             5
                11/70           1.1             15
                Alto (24)       0.3/7.2         1/24
                Lisp (26)       2-6/104         1/26

--
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: Wed, 31 Oct 2001 11:58:49 GMT

Dennis Ritchie writes:
One fact about both was that there were two separate character encodings and sets of golf-balls. The "correspondence" series were used with the office/typist Selectrics and offered a nicer selection of font styles. The other encoding was more oriented to computer use. I forget its generic name, but it was typified and often named the 938 character set after its part number. (There was also the APL character golf-ball; I can't remember which it resembled more).

& pulling out trusty cp-67 manual ... 2741 keyboard

compared to current PC keyboards the "return" key was two rows high (eliminating the left/right bracket keys). The tab key on the left was two rows high, eliminating the approximation/reverse quote key.

On the 2741, feature Receive Interrupt (#4708) was required and either feature Transmit Interrupt (#7900) or Transmit Interrupt Control (RPQ E40681) was required. Also feature Print Inhibit (#5501) was desirable.

2741 ... standard selectric (correspondence) configuration

looks a little more like curent PC keyboard

except there was +/- combo symbol above the one/1 cent-sign above 6 only one key to the right of the P, uppercase "degree" symbol, lowercase was ! the comma key to the right of the M was comma for both lower & upper case the period key to the right of the comm, was period for both lower & upper case

2741 ... PTTC/EBCD (computer) configuration

more different than current PC keyboard.

< less-than above the two ; semi-colon above the three : colon above the four ' single quote above the six > greater than above the seven key next to the backspsace had "&" in lowercase (instead of equal/=) key next to the P had lower case @ sign and upper case cent sign key next to the L had lower case $/dollar, and uppercase ! key between "$" & return had lowercase #/pound and uppercase double-quote the comma key (next to M) had uppercase !/exclamation the period key had uppercase "not" sign.

I still have an APL PTTC/EBCD ball.

The correspondence/PTTC encodings were different. CP-67 would get initial incoming 2741 message (assumed to be login), use the PTTC->EBCDIC translate table and check for an "l/L", if it wasn't an "l/L" it would check for a "y/Y". If it was an "y/Y", it would assume that it was a correspondence terminal and retranslate the message with the correspondence->EBCDIC translate table (and then check again for "l/L").

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

The 33 KSR (keyboard send/receive) is supported by CP-67

The control panel to the right of the keyboard contains six buttons below the telephone dial, and two lights, a button, and the NORMAL-RESTORE knob above the dial. The buttons and lights are as follows:

ORIG (ORIGINATE). This button obtains a dial tone before dialing. The volume control ont eh loadpseaker (under the keybarod shelf to the right) should be turned up such that the dial tone is audible.

CLR (CLEAR). This button, wheen depressed, turns off the typewriter

ANS (Answer). This button is not used by CP-67

TST (TEST). This button is used for testing purposes only

LCL (Local)> This button turns on the typerwriter for local or offline use.

BUZ-RLS (Buzzer-release). This button turns off the buzzer that warns of a low paper supply.

BRK-RLS (Break-Release). This buttons unlocks the keyboard after program execution has been interrupted by the BREAK key.

REST. This light is not used by CP-67

NORMAL-RESTORE. This knob is set to NORMAL, except to change the ribbon, in which case the knob is twisted to the OUT-OF-SERV light.

OUT-OF-SERV (Out of Service). This light goes on when the NORMAL-RESTORE knob is pointed to it for ribbon changing.

The KSR (Keyboard Send/Receive) model of the teletype Type 35 terminal is supported by CP-67.

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

MVS History (all parts)

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MVS History (all parts)
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 31 Oct 2001 12:19:53 GMT

slightly more complete


           2301       fixed-head/track (2303 but r/w four heads in parallel)
2303       fixed-head/track r/w single head (1/4th rate of 2301)
Corinth    2305-1     fixed-head/track
Zeus       2305-2     fixed-head/track
2311
2314
           2321       data-cell "washing machine"
?Piccolo   3310       FBA
Merlin     3330-1
Iceberg    3330-11
Winchester 3340-35
3340-70
           3344       (3350 physical drive simulating multiple 3340s)
Madrid     3350
NFP        3370       FBA
Florence   3375       3370 supporting CKD
Coronado   3380 A04, AA4, B04
EvergreenD 3380 AD4, BD4
EvergreenE 3380 AE4, BE4

           3830       horizontal microcode engine

Cybernet   3850       MSS (also Comanche & Oak)

Cutter     3880       jib-prime (vertical) microcode engine
Ironwood   3880-11    (4kbyte/page block 8mbyte cache)
Sheriff    3880-13    (full track 8mbyte cache)
Sahara     3880-21    (larger cache for "11")
??         3880-23    (larger cache for "13")

misc. other refs:
https://www.garlic.com/~lynn/95.html#8 3330 Disk Drives
https://www.garlic.com/~lynn/99.html#6 3330 Disk Drives

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

next, previous, index - home