List of Archived Posts
2006 Newsgroup Postings (10/3 - 10/22)
- What data is encoded?
- Info on Compiler System 1 (Univac, Navy)?
- History of IBM Systems
- THE on USS?
- Why not 2048 or 4096 bit RSA key issuance?
- Why not 2048 or 4096 bit RSA key issuance?
- Greatest Software Ever Written?
- Very slow booting and running and brain-dead OS's?
- Google launches search engine for finding source code
- Why not 2048 or 4096 bit RSA key issuance?
- Why not 2048 or 4096 bit RSA key issuance?
- Why not 2048 or 4096 bit RSA key issuance?
- Languages that should have made it but didn't
- Newisys Horus & AMD Opteron
- Ultra simple computing
- THE on USS?
- memory, 360 lcs, 3090 extended store, etc
- bandwidth of a swallow (was: Real core)
- IDC: Virtual machines taking over the world
- Very slow booting and running and brain-dead OS's?
- real core
- Very slow booting and running and brain-dead OS's?
- Why these original FORTRAN quirks?
- Why magnetic drums was/are worse than disks ?
- Curiousity: CPU % for COBOL program
- VM SPOOL question
- Why these original FORTRAN quirks?
- Why these original FORTRAN quirks?
- Storage Philosophy Question
- Why these original FORTRAN quirks?
- Why magnetic drums was/are worse than disks ?
- Why magnetic drums was/are worse than disks ?
- Why magnetic drums was/are worse than disks ?
- Why magnetic drums was/are worse than disks ?
- Basic Question
- Turbo C 1.5 (1987)
- Turbo C 1.5 (1987)
- Turbo C 1.5 (1987)
- Design life of S/360 components?
- Why these original FORTRAN quirks?
- Ranking of non-IBM mainframe builders?
- Ranking of non-IBM mainframe builders?
- Ranking of non-IBM mainframe builders?
- Ranking of non-IBM mainframe builders?
- Universal constants
- Why magnetic drums was/are worse than disks ?
- Why these original FORTRAN quirks?
- 5692 and 6SN7 vs 5963's for computer use
- 5692 and 6SN7 vs 5963's for computer use
- Why these original FORTRAN quirks?
- Ranking of non-IBM mainframe builders?
- Ranking of non-IBM mainframe builders?
- 5692 and 6SN7 vs 5963's for computer use
- Is the teaching of non-reentrant HLASM coding practices ever defensible?
- Why these original FORTRAN quirks?
- Is the teaching of non-reentrant HLASM coding practices ever defensible?
- Turbo C 1.5 (1987)
- Turbo C 1.5 (1987)
- IA64 and emulator performance
- Why magnetic drums was/are worse than disks ?
- IA64 and emulator performance
- Is the teaching of non-reentrant HLASM coding practices ever defensible?
- Microsoft to design its own CPUs - Next Xbox In Development
- Microsoft to design its own CPUs - Next Xbox In Development
- Is the teaching of non-reentrant HLASM coding practices ever defensible?
- Paranoia..Paranoia..Am I on the right track?.. any help please?
- Why these original FORTRAN quirks?; Now : Programming practices
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What data is encoded?
Newsgroups: sci.crypt
Date: Tue, 03 Oct 2006 18:30:48 -0600
"Dave" <dave42972000@yahoo.com> writes:
Where can I find a descrition of the RC4 and MD5 algorithms, and just
how strong are they?
rfc
1321 I
The MD5 Message-Digest Algorithm, Rivest R., 1992/04/16 (21pp)
(.txt=35222) (See Also 1320)
one of the things i've done for my rfc index
http://www.garlic.com/~lynn/rfcietff.htm
is a collection of all RFC summaries that reference md5
http://www.garlic.com/~lynn/rfcmd5.htm
in the rfc summaries, clicking on the ".txt=nnnn" field retrieves
the actual rfc.
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Info on Compiler System 1 (Univac, Navy)?
Newsgroups: alt.folklore.computers
Date: Wed, 04 Oct 2006 14:02:57 -0600
"Sarr J. Blumson" <sarr@punchout.gpcc.itd.umich.edu> writes:
Jean Sammet's book "A History of Programming Languages" might help, but I
don't actually have a copy.
for cross thread drift ... recent comment about boston programming
center on 3rd flr of 545 tech sq
http://www.garlic.com/~lynn/2006r.html#41 Very slow booting and running and brain-dead OS's?
sammet was at the boston programming center as the vm370 development
group was absorbing it. a few people (sammet, rochester, etc) in the
boston programming center got attached to the science center as the
boston programming center was being absorbed ... and then moved out to
old sbc bldg. in burlington mall.
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: History of IBM Systems
Newsgroups: alt.folklore.computers
Date: Thu, 05 Oct 2006 08:55:49 -0600
History of IBM Systems
http://www.osnews.com/story.php?news_id=16072
New to IBM Systems
http://www-128.ibm.com/developerworks/eserver/newto/?ca=dgr-lnxw01IBM-Systems
a recent comp.arch post with a little more detail for some of the pieces
http://www.garlic.com/~lynn/2006r.html#49 Seeking info on HP FOCUS (HP 9000 Series 500) and IBM ROMP CPUs from early 80's
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: THE on USS?
Newsgroups: bit.listserv.ibm-main
Date: Thu, 05 Oct 2006 09:36:05 -0600
Dan Espen <daneNO@MORE.mk.SPAMtelcordia.com> writes:
Yes, I should have been clearer.
I prefer ISPFs exclude even though xemacs has multiple ways
to hide text, the simpler whole line approach and the first/last
stuff just seems better.
The ISPF bounds stuff and shifting is pretty good too.
emacs has a bunch of 'rectangle' facilities, but ISPF wins again
with a simple powerful interface.
If I'm doing CLISTs and PANELs, ISPFs models/help wins again.
On the other hand being able to use the same editor for editing,
mail, news, file managment, downloads, etc. is what puts XEmacs light
years ahead.
My opinion, anyway.
for nearly anything that emacs doesn't do ... that ISPF might ... you
write some lisp code. nearly 20 years ago, there was some XEDIT stuff
that weren't in emacs ... that somebody wrote some lisp code to
emulate. trivial one that i have still laying around is ALL (display
just the lines containing search argument)
display-function for all ...
all is an interactive compiled Lisp function in `all'.
(all REGEXP &optional NLINES)
Show all lines in the current buffer containing a match for REGEXP.
If a match spreads across multiple lines, all those lines are shown.
Each line is displayed with NLINES lines before and after, or -NLINES
before if NLINES is negative.
NLINES defaults to `list-matching-lines-default-context-lines'.
Interactively it is the prefix arg.
The lines are shown in a buffer named `*All*'.
Any changes made in that buffer will be propagated to this buffer.
... snip ...
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why not 2048 or 4096 bit RSA key issuance?
Newsgroups: microsoft.public.platformsdk.security,microsoft.public.security.crypto
Date: Thu, 05 Oct 2006 16:02:43 -0600
"Mitch Gallant" <jensigner@community.nospam> writes:
I thought I had heard somewhere that the CA should have a larger keysize
than the issued key size under it .. maybe my memory fails me on this. That
is why I pointed that out.
in theory of security proportional to risk ... somebody would choose a
key size supposedly sufficient to protect what is at risk, i.e. what
bad things can happen if somebody compromised your key, with an
implicit assumption that larger key sizes are harder to compromise
(and therefor provide greater security)
the issue with PKI, certification authorities, digitial certificates,
etc ... is that the compromise of a CA signing key brings down the
whole infrastructure ... not necessarily just limited to every
key/certificate that a specific PKI/CA key has signed
a key/certificate signing key is preloaded into hundreds of millions
of systems. all of these systems are setup that anything they get that
has been signed by one of the preloaded keys ... is assumed to be
trusted. if any one of the preloaded keys has been compromised ... an
attacker can generate counterfeit keys/certificates for all possible
covered operations (potentially a counterfeit for every possible
key/certificate that has ever existed could be created ... but instead
of including the correct public key ... the attacker could substitute
any key of their choosing).
as a result, what is at risk ... isn't even limited to just the
keys/certificates that may have already been signed by a specific
compromised PKI/CA key ... but the totallity of all possible digital
certificates that an attacker might generate with a compromised key
... and ALL possible susceptible systems and infrastructures
that have been programmed to trust a specific PKI/CA key
... aka it isn't just the issued key "sizes" under it (i.e. all the
keys/certificates signed with the specific CA key) .... it is ALL
possible keys/certificates that an attacker might possibly generate
... and ALL possible systems and infrastructures that are vulnerable
because they are setup up to trust some specific PKI/CA key.
misc. past collected posts mentioning threats, vulnerabilities, compromises,
exploits or fraud
http://www.garlic.com/~lynn/subintegrity.html#fraud
misc. past collected posts mentioning assurance
http://www.garlic.com/~lynn/subintegrity.html#assurance
for a little drift, recent thread on
http://www.garlic.com/~lynn/aadsm25.htm#37 How the Classical Scholars dropped security from the canon of Computer Science
http://www.garlic.com/~lynn/aadsm25.htm#38 How the Classical Scholars dropped security from the canon of Computer Science
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why not 2048 or 4096 bit RSA key issuance?
Newsgroups: microsoft.public.platformsdk.security,microsoft.public.security.crypto
Date: Thu, 05 Oct 2006 16:39:25 -0600
"Mitch Gallant" <jensigner@community.nospam> writes:
Not always the case ..
e.g. heavily used online banking service:
https://www4.bmo.com/
SSL server cert is 1024 bit
issued by a *1024* bit CA
"Entrust.net Secure Server Certification Authority"
Validity Period 1999 - 2019
So obviously, even in the hopefully high security future looking online
banking industry, we can easily find poor key practices .
as per previous post
http://www.garlic.com/~lynn/2006s.html#4 Why not 2048 or 4096 bit RSA key issuance?
what is at risk isn't just limited to the keys/certificates that have
been signed by a specific PKI/CA key .... what is at risk are all the
systems and infrastructures that have the specific PKI/CA key
preloaded and are programmed to trust their preloaded PKI/CA keys.
a compromised PKI/CA key can be used by an attacker to turn around and
sign nearly any sort of key/certificate ... and then ALL the
victim systems/infrastructures are at risk ... because they are
(generally) configured to (equally) trust all their preloaded PKI/CA
keys.
an institution choosing to contract from a PKI/CA using a larger
signing key size ... makes little difference; as traditionally the
case, security is only as good as the weakest link. since browsers,
systems, and other infrastructures tend to treat all preloaded PKI/CA
keys equally ... the compromise of any single PKI/CA key puts the
whole infrastructure at risk ... not just the keys/certificates that
have been signed by the specific compromised PKI/CA signing key.
In theory, any compromised PKI/CA signing key can be used to generate
all possible counterfeit digital certificates (with any public key of
the attackers choice) ... and the systems/infrastructure don't
differentiate between what specific preloaded PKI/CA signing keys have
signed ... all preloaded PKI/CA signing keys are treated equally.
a similar, but different kind of security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61
and yet another variation involving yes card compromise, again
the issue isn't proportional to the original card ... it is
proportional to all the possible point-of-sale terminals that can be
attacked with (large numbers of) counterfeit cards
http://www.garlic.com/~lynn/subintegrity.html#yescard
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Greatest Software Ever Written?
Newsgroups: alt.folklore.computers
Date: Thu, 05 Oct 2006 18:06:47 -0600
Charlton Wilbur <cwilbur@mithril.chromatico.net> writes:
I should perhaps add that UMass's building problems are caused both by
area-inappropriate building styles (flat roofs) and area-inappropriate
building materials (concrete). I think they could have gotten away
with either, but not both.
how 'bout repaving mass pike nearly every year (because of frost
heaves)?
or the windows popping out of the prudential building ... or even
bldg. ?? on the mit campus.
not to be too off topic, but bringing up some recent posts about
computers and software
http://www.garlic.com/~lynn/aadsm25.htm#37 How the Classical Scholars dropped security from the canon of Computer Science
http://www.garlic.com/~lynn/aadsm25.htm#38 How the Classical Scholars dropped security from the canon of Computer Science
http://www.garlic.com/~lynn/aadsm25.htm#39 How the Classical Scholars dropped security from the canon of Computer Science
misc. past posts mentioning issues with mass pike:
http://www.garlic.com/~lynn/2002i.html#28 trains was: Al Gore and the Internet
http://www.garlic.com/~lynn/2002j.html#68 Killer Hard Drives - Shrapnel?
http://www.garlic.com/~lynn/2002l.html#67 The problem with installable operating systems
http://www.garlic.com/~lynn/2002l.html#69 The problem with installable operating systems
http://www.garlic.com/~lynn/2003j.html#11 Idiot drivers
http://www.garlic.com/~lynn/2006g.html#49 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#36 The Pankian Metaphor
http://www.garlic.com/~lynn/2006h.html#39 The Pankian Metaphor
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Very slow booting and running and brain-dead OS's?
Newsgroups: alt.folklore.computers
Date: Fri, 06 Oct 2006 08:19:07 -0600
jmfbahciv writes:
Now think about why the OS can't be restarted. I see no problem
with "restarting" sectors of it, if the code can be isolated.
Save the state of the machine and its data is the problem. Our
implementation started to figure this out.
part of the micro-kernel genre ... core stuff was smallest unit
possible and everything else was in partitioned address spaces.
the other was replicated kernels on replicated hardware ... basically
do rolling restart.
similar, but different was loosely-coupled configurations (form of
replication ... but also used for capacity) and migrate
processes/applications across different processor complexes. this was
done by some of the cp67/vm370 based commercial timesharing service
bureaus
http://www.garlic.com/~lynn/subtopic.html#timeshare
as they moved to world-wide, 7x24 operation in the early to
mid-70s. particular pieces of hardware (including whole complexes) had
to be taken out of service for periodic maintenance (but also
applicable to kernal maintenance). recent post in this tread
http://www.garlic.com/~lynn/2006r.html#41 Very slow booting and running and brain-dead OS's?
i.e. from user/application standpoint using replicated systems (and
things like process/workload migration) for masking system
downtime/outage can be just as effective as making each individual
component instantaneously restartable. this was also part of our ha/cmp
product
http://www.garlic.com/~lynn/subtopic.html#hacmp
in the genre of partitioning and moving services out of the kernel ... post
somewhat about contrast of moving SSL processing into the kernel ... vis-a-vis
attempts at moving tcp/ip protocol stack out of the kernel in coyotos
a partitioned, highly secure, capability based system
http://www.garlic.com/~lynn/2006p.html#13 What part of z/OS is the OS?
that traces its heritage back thru keykos and gnosis
in the early/mid 80s ... i had undertaken to move a large remaining
component out of the vm370 kernel ... the "spool file system". the
justification was that vm370 networking was dependent on spool file
system and it was starting to represent a system thruput bottleneck
for our HSDT project
http://www.garlic.com/~lynn/subnetwork.html#hsdt
I needed to improve the thruput by 10-100 times ... which required a
significant restructuring. i figured that while i was at it, i would
also move the processing out of the kernel. this was also somewhat
improve the vm370 reboot time ... which was already pretty fast ...
as the previous post (in this thread) also alludes to.
misc. past posts mentioning spool file system rewrite:
http://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)
http://www.garlic.com/~lynn/2003b.html#33 dasd full cylinder transfer (long post warning)
http://www.garlic.com/~lynn/2003b.html#44 filesystem structure, was tape format (long post)
http://www.garlic.com/~lynn/2003b.html#46 internal network drift (was filesystem structure)
http://www.garlic.com/~lynn/2003g.html#27 SYSPROF and the 190 disk
http://www.garlic.com/~lynn/2003k.html#26 Microkernels are not "all or nothing". Re: Multics Concepts For
http://www.garlic.com/~lynn/2003k.html#63 SPXTAPE status from REXX
http://www.garlic.com/~lynn/2004m.html#33 Shipwrecks
http://www.garlic.com/~lynn/2005j.html#54 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005j.html#58 Q ALLOC PAGE vs. CP Q ALLOC vs ESAMAP
http://www.garlic.com/~lynn/2005n.html#36 Code density and performance?
http://www.garlic.com/~lynn/2005s.html#28 MVCIN instruction
http://www.garlic.com/~lynn/2005s.html#46 Various kinds of System reloads
http://www.garlic.com/~lynn/2005s.html#50 Various kinds of System reloads
http://www.garlic.com/~lynn/2006e.html#36 The Pankian Metaphor
http://www.garlic.com/~lynn/2006k.html#51 other cp/cms history
http://www.garlic.com/~lynn/2006o.html#64 The Fate of VM - was: Re: Baby MVS???
http://www.garlic.com/~lynn/2006p.html#11 What part of z/OS is the OS?
http://www.garlic.com/~lynn/2006q.html#27 dcss and page mapped filesystem
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Google launches search engine for finding source code
Newsgroups: bit.listserv.ibm-main
Date: Fri, 06 Oct 2006 08:27:21 -0600
jchase@ibm-main.lst (Chase, John) writes:
STM R14,R12 will get you 50 or so.... but STM 14,12,12(13) returns
nothing.
see recent thread posting in comp.arch
http://www.garlic.com/~lynn/2006r.html#8 should program call stack grow upward or downwards?
possibly just hasn't perculated thru the index yet.
i archive posts and then do various kinds of cross-index on garlic.com
web pages with hrefs. there is extremely high ratio of hrefs to
aggregate size of all files (one file has something like 35k hrefs).
from the hit log ... it would appear that major web crawlers use pages
as daily regression test.
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why not 2048 or 4096 bit RSA key issuance?
Newsgroups: microsoft.public.platformsdk.security,microsoft.public.security.crypto
Date: Fri, 06 Oct 2006 10:15:31 -0600
lelteto <lelteto@discussions.microsoft.com> writes:
It is true that "compromise" of a CA signing key has greater consequences -
and that's why most (sensible) CAs use 2048-bit keys. And hopefully they keep
that key in hardware-only so it cannot be exported in the clear.
Most other keys' compromise, however, happens not because the private key is
recovered (calculated) from the public key but because of poor security of
the private key (eg. stored on-disk, computer compromised - in that case even
password protecting the key will not help). In the latter case key size is
indifferent...
re:
http://www.garlic.com/~lynn/2006s.html#4 Why not 2048 or 4096 bit RSA key issuance?
http://www.garlic.com/~lynn/2006s.html#5 Why not 2048 or 4096 bit RSA key issuance?
yes ... frequently there are much easier paths to compromise than
brute force ... however, the issue of any PKI/CA key (preloaded into
millions of different browsers, systems, infrastructures) ... being
compromised ... regardless of the kind of compromise ... still puts
the whole infrastructure at risk ... i.e. the infrastructure is
vulnerable to its weakest link ... whether the kind of weakest
link represents key size or any of myriad of other security processes.
Refed: **, - **, - **, - **
From: lynn@garlic.com
Subject: Re: Why not 2048 or 4096 bit RSA key issuance?
Date: Sat, 07 Oct 2006 17:04:24 -0700
Newsgroups: microsoft.public.platformsdk.security,microsoft.public.security.crypto
re:
http://www.garlic.com/~lynn/2006s.html#4 Why not 2048 or 4096 bit RSA key issuance?
http://www.garlic.com/~lynn/2006s.html#5 Why not 2048 or 4096 bit RSA key issuance?
http://www.garlic.com/~lynn/2006s.html#9 Why not 2048 or 4096 bit RSA key issuance?
so if we talk about a system availability/integrity ... a specific
system may have two nines (0.99) availability. if you use two such
systems in a replicated fashion ... then non-availability is the
probability that all systems fail at the same time ... the product of
the inverse of their availability ... i.e. .01*.01=.0001 ... which
inverted to give availability is four nines (0.9999). a little drift
... to having done scalable high availability product in the past
http://www.garlic.com/~lynn/subtopic.html#hacmp
a treat model for the PKI/CA case ... is you have an infrastructure
with hundreds of millions of systems, each with their own local copy
of say around forty (or more) pre-loaded PKI/CA keys .... then the
whole infrastructure can be compromised if any one of those PKI/CA
keys is compromised. The issue is that the most PKI/CA implementations
don't differentiate between their preloaded PKI/CA keys ... they are
effectively all treated as equal.
so it can make little difference that a single one of the
certification authorities has 4096bit key and physically protect it
with many levels of hardware and armed guards ... if none of the other
thirty-none do. This is the well known security line about
infrastructures only being as strong as the weakest link.
the preloaded forty PKI/CA keys aren't analogous to the
redundant/availability scenario where it would require compromising
all forty PKI/CA keys before the infrastructure is compromised. in
the typical PKI/CA impelementation scenario ... it only requires
compromise of just one of the preloaded PKI/CA keys to result in a
compromise of the whole infrastructure.
the threat model isn't an attack against the certification authorities
... the threat model is to use a compromise of any one of the
preloaded, (equally) trusted PKI/CA keys to attack all of the hundreds
of millions of systems that are part of the PKI/CA infrastructure
sharing the same set of PKI/CA keys. Say business "123" had a digital
certificate signed/issued by an extremely high integrity certification
authority "ZED". An attacker can compromise the private key of any
certification authority (possibly one with extremely low integrity).
The attacker then can generate their own counterfeit digital
certificate for business "123" and impersonate that business. The issue
is that in the PKI/CA operations, the hundreds of millions of systems
with preloaded trusted PKI/CA public keys don't differentiate between
those public keys and/or who has issued a digital certificate.
the first approximation to the threat level to the overall
infrastructure is to take the ease of compromising the weakest link
(PKI/CA key) by any means possible (brute force attack on the key,
physical attack against the key, insider subterfuge, ....)
the actual probability of compromise to the overall infrastructure is
the sum of the probabilities of compromising the individual PKI/CA
keys. to the first approximation, doubling the number of preloaded
PKI/CA keys in all of the hundreds of millions of system components
... doubles the probability of an overall infrastructure compromise.
This is not the redundant/available scenario where all components have
to be compromised/fail before there is a system loss ... this is the
scenario where the compromise of any one component can compromise the
overall infrastrucutre ... and as such, if there were a doubling of
the number of such components ... there is a corresponding doubling
the possibility that a overall infrastructure compromise could occur.
(this is independent of the variationd/differences that there might a
huge difference in the failure/compromise probability of different
PKI/CA operations; aka weakest link scenario)
there have been discussions in the past about what might be the
situation for PKI/CA keys that belong to operations that have gone out
of business ... but the related PKI/CA public keys are still carried
in hundreds of millions of software components. Is it possible that
the PKI/CA private key physical protection might be relaxed if the
business no longer exists (and might it be easier to take down the
whole infrastructure by attacking thru such a key ... than trying to
go after
Refed: **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: Re: Why not 2048 or 4096 bit RSA key issuance?
Date: Sat, 07 Oct 2006 17:25:17 -0700
Newsgroups: microsoft.public.platformsdk.security,microsoft.public.security.crypto
re:
http://www.garlic.com/~lynn/2006s.html#4 Why not 2048 or 4096 bit RSA key issuance?
http://www.garlic.com/~lynn/2006s.html#5 Why not 2048 or 4096 bit RSA key issuance?
http://www.garlic.com/~lynn/2006s.html#9 Why not 2048 or 4096 bit RSA key issuance?
http://www.garlic.com/~lynn/2006s.html#10 Why not 2048 or 4096 bit RSA key issuance?
as part of doing the aads chip strawman in the 98 timeframe ...
http://www.garlic.com/~lynn/x959.html#aadsstraw
we had a requirement being able to do a digital signature within
transit gate timing (100-200 milliseconds) and within power profile
of an iso14443 proximity chip.
in that time-frame RSA was taking significantly longer. one of the
attempts to get down the RSA time-frame was to .. was add an 1100-bit
multiplier to such chips ... however that significantly drives up the
power requirements ... making proximity impractical.
so the only thing that turned out to be practical for the AADS chip
strawman was ECC.
as to the other, we were called in to consult with this small
client/server startup that wanted to do payments on their server ...
they had this technology called SSL and the payment stuff has since
come to be called electronic commerce
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
a fundamental part of SSL was that it would provide some assurance
that the website that the user thot they were talking to, was in fact
the website they were talking to. the browser validates the server's
ssl domain name certificate and then checks that the domain name from
the URL that the user typed in is the same as the doman name from the
digital certificate.
the problem was that most merchant sites found out that SSL cut their
thruput by 80-90 percent ... so instead of using SSL for the whole
shopping experience (starting with the URL typed in by the user)
... it was reduced to only being used for checkout/payment part
... where the user clicked on a (payment/checkout) button provided by
the merchant site.
the problem now is that both the URL and the digital certificate is
being provided by the webserver .... and it would take a really dumb
attacker not to make sure that the URL they were using didn't match
the domain name in the certificate they provided. So for the most part
SSL is no longer being used to validate that the website that the user
thinks they are talking to, is in fact, the website they are talking
to; instead SSL is being used to validate that the whoever the website
claims to be, is in fact, the website that it claims to be.
some of the (banking) email phishing/scams have taken advantage of the
early ecommerce example and include a URL in the body of the email
that can be clicked on. they then have a website that may spoof some
better known website (possibly using MITM attack), for which they have
a valid digital certificate.
the spamming countermeasure has been if the body of the email actually
lists the URL as part of the "click" ... and that URL doesn't actually
match the URL given the browser, they raise some sort of warning.
however, if the click field just contains some sort of other text ...
there is nothing to compare against.
collection of past postings mentioning ssl domain name digital
certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 8 Oct 2006 06:23:14 -0700
Subject: Re: Languages that should have made it but didn't
Tim Bradshaw wrote:
Lisp systems (for instance) have all these issues as well (though I
suspect recent Java GCs are more sophisticated than those of many
current Lisp systems).
as do APL. early apl\360 swapped relatively small workspaces, 16k-32k
bytes ... so the issue of using all of (availabile workspace) memory
and then garbage collect was relatively trivial.
in early 70s, porting apl\360 to cms for cms\apl product ... eliminated
lots of stuff like the monitor that did tasking and swapping (since
that was handled by underlying cp67). however, the garbage collection
had to be extensively reworked for the relatively large (several
hundred kbytes to a few mbytes) virtual paged memory. the original
apl\360 code exhausting a workspace under cms\apl resulted in horrible
paging characteristics. the garbage collection was one of the things
that went thru a number of iterations attempting to adapt it to a page
virtual memory environment
lots of past posts about apl and/or HONE (large online internal
timesharing service ... mostly cms\apl .. later apl\cms, etc as apl
evolved ... based applications ... providing support for world-wide
field, sales, and marketing)
http://www.garlic.com/~lynn/subtopic.html#hone
misc. past posts mentioning garbage collection
http://www.garlic.com/~lynn/93.html#5 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/94.html#7 IBM 7090 (360s, 370s, apl, etc)
http://www.garlic.com/~lynn/97.html#4 Mythical beasts (was IBM... mainframe)
http://www.garlic.com/~lynn/99.html#20 APL/360
http://www.garlic.com/~lynn/99.html#38 1968 release of APL\360 wanted
http://www.garlic.com/~lynn/2000g.html#30 Could CDR-coding be on the way back?
http://www.garlic.com/~lynn/2001c.html#31 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001c.html#33 database (or b-tree) page sizes
http://www.garlic.com/~lynn/2001d.html#18 Drawing entities
http://www.garlic.com/~lynn/2001f.html#59 JFSes: are they really needed?
http://www.garlic.com/~lynn/2001i.html#20 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001n.html#0 TSS/360
http://www.garlic.com/~lynn/2001n.html#4 Contiguous file system
http://www.garlic.com/~lynn/2002c.html#29 Page size (was: VAX, M68K complex instructions)
http://www.garlic.com/~lynn/2002c.html#45 cp/67 addenda (cross-post warning)
http://www.garlic.com/~lynn/2002e.html#8 What are some impressive page rates?
http://www.garlic.com/~lynn/2002e.html#50 IBM going after Strobe?
http://www.garlic.com/~lynn/2002j.html#5 HONE, xxx#, misc
http://www.garlic.com/~lynn/2002l.html#36 Do any architectures use instruction count instead of timer
http://www.garlic.com/~lynn/2002m.html#4 Handling variable page sizes?
http://www.garlic.com/~lynn/2002q.html#47 myths about Multics
http://www.garlic.com/~lynn/2003f.html#15 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#21 "Super-Cheap" Supercomputing
http://www.garlic.com/~lynn/2003g.html#5 Any DEC 340 Display System Doco ?
http://www.garlic.com/~lynn/2003j.html#32 Language semantics wrt exploits
http://www.garlic.com/~lynn/2003n.html#8 The IBM 5100 and John Titor
http://www.garlic.com/~lynn/2004.html#14 Holee shit! 30 years ago!
http://www.garlic.com/~lynn/2004c.html#7 IBM operating systems
http://www.garlic.com/~lynn/2004c.html#21 PSW Sampling
http://www.garlic.com/~lynn/2004q.html#5 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2004q.html#31 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005f.html#63 Moving assembler programs above the line
http://www.garlic.com/~lynn/2005h.html#15 Exceptions at basic block boundaries
http://www.garlic.com/~lynn/2005j.html#62 More on garbage collection
http://www.garlic.com/~lynn/2005k.html#17 More on garbage collection
http://www.garlic.com/~lynn/2005n.html#18 Code density and performance?
http://www.garlic.com/~lynn/2005n.html#22 Code density and performance?
http://www.garlic.com/~lynn/2005o.html#5 Code density and performance?
http://www.garlic.com/~lynn/2005o.html#34 Not enough parallelism in programming
http://www.garlic.com/~lynn/2006b.html#23 Seeking Info on XDS Sigma 7 APL
http://www.garlic.com/~lynn/2006e.html#20 About TLB in lower-level caches
http://www.garlic.com/~lynn/2006j.html#3 virtual memory
http://www.garlic.com/~lynn/2006j.html#24 virtual memory
http://www.garlic.com/~lynn/2006o.html#13 The SEL 840 computer
http://www.garlic.com/~lynn/2006o.html#23 Strobe equivalents
From: lynn@garlic.com
Newsgroups: comp.arch
Date: 8 Oct 2006 08:06:26 -0700
Subject: Re: Newisys Horus & AMD Opteron
Zak wrote:
If only driving one would require a truck-class driver's license,
and presumably the same speed limit as for trucks. Or a more
radical idea: replace speed limits with energy limits (or would that
be impulse limits...)?
some number of SUVs meet truck weight classification and are eligible
for significnat tax break as commerical vehicle. there was an effort
in cal. to get this strictly enforced ... among other things, such
commercial vehicles are prohibited on most residential streets
(i.e. if you were going to buy such a vehicle ... you could take the
tax break ... but you also had to leave it on the border of your
residential area and walk the rest of the way).
From: lynn@garlic.com
Newsgroups: comp.arch
Date: 8 Oct 2006 08:17:50 -0700
Local: Sun, Oct 8 2006 11:17 am
Subject: Re: Ultra simple computing
russell kym horsell wrote:
Reputation of a source is a poor 2nd to looking for inconsitencies
in the proffered argument. E.g. in this case replacing a
"complicated processor" with a "mess of simple chips" doesn't seem
to get away from complexity at all, but does manager to move off
into the stratosphere in terms of hand-waving naive vagueness.
Unreliability can not be avoided. Complexity can not be avoided.
These things can only be mitigated. To solve certain types of
problems requires certain types of resources. The best you can hope
to do (and best itself is a vague concept, as it turns out) is avoid
*unnecessary* unreliability or complexity.
partitioning has been a long held method of managing complexity.
however, the issue can arise where the partitioning techniques are
orthogonal to the problem at hand. the issue does the partitioning
paradigm somehow relate to the structure/nature of the problem.
when we were doing ha/cmp product ... the partitioning for no single
point of failure attempted to match the partitioning against the
components at hand and the problems to be addressed. there had to be a
fairly detailed analysis of system operation and failure modes
http://www.garlic.com/~lynn/subtopic.html#hacmp
Refed: **, - **, - **
From: lynn@garlic.com
Newsgroups: bit.listserv.ibm-main, alt.folklore.computers
Date: 9 Oct 2006 06:00:24 -0700
Subject: Re: THE on USS?
Efinnel...@ibm-main.lst wrote:
CMS under MVS has been parked on the shelf next to CLIK(clist compiler)
since mid-eighties "for marketing considerations" whatever that means.
spring '82 workshop that included talk on cms under mvs.
http://www.garlic.com/~lynn/96.html#4a
part of the issue was that cms had been personal computing on
mainframes since the 60s (on cp67 when it was still called cambridge
monitor system ... before "CMS" was renamed to conversational monitor
system); this included reasonable interactive response. this was period
when trivial interactive response had expectation of quarter second or
less with cms .... and anything equivalent under mvs on similar
hardware was difficult or impossible to get under one second response.
part of this was MVS use of multi-track search for vtocs and pds
directories. for a period, sjr datacenter ... where original
relational/sql was implemented (under vm370)
http://www.garlic.com/~lynn/subtopic.html#systemr
there was vm/cms on 370/158 and mvs on 370/168 and all disk controllers
had connections to channels on both processors. there was strict
operational guidelines that disks for mvs system weren't allowed to be
mounted on "vm" drives (aka related to disk controllers nominally
exclusively reserved for vm/cms use)
there were a couple incidents when the operators accidentially violated
the guideline and mounted a "mvs" 3330 on a vm/cms string. within 5-10
minutes the datacenter was getting calls from irate cms users about
severe degradation in cms response.
the issue was that mvs normal use of disk multi-track search has
significant adverse effects on interactive response. users in an MVS
environment never experience the with and w/o effects ... so just
become accustomed to dismal interactive response. the functional
features are only a part of the cms interactive experience vis-a-vis
MVS ... because of the other downside of interactive operation in MVS,
it hardly justifies offering CMS capability in MVS environment.
misc. other posts about mutli-track search
http://www.garlic.com/~lynn/subtopic.html#dasd
misc. past posts mentioning ispf
http://www.garlic.com/~lynn/2000d.html#17 Where's all the VMers?
http://www.garlic.com/~lynn/2001m.html#33 XEDIT on MVS
http://www.garlic.com/~lynn/2002m.html#52 Microsoft's innovations [was:the rtf format]
http://www.garlic.com/~lynn/2003k.html#0 VSPC
http://www.garlic.com/~lynn/2003o.html#42 misc. dmksnt
http://www.garlic.com/~lynn/2004c.html#26 Moribund TSO/E
http://www.garlic.com/~lynn/2004g.html#43 Sequence Numbbers in Location 73-80
http://www.garlic.com/~lynn/2005j.html#7 TSO replacement?
http://www.garlic.com/~lynn/2005j.html#8 TSO replacement?
http://www.garlic.com/~lynn/2005q.html#15 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005t.html#40 FULIST
http://www.garlic.com/~lynn/2006k.html#50 TSO and more was: PDP-1
http://www.garlic.com/~lynn/2006o.html#21 Source maintenance was Re: SEQUENCE NUMBERS
http://www.garlic.com/~lynn/2006p.html#13 What part of z/OS is the OS?
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: memory, 360 lcs, 3090 extended store, etc
Date: Wed, 11 Oct 2006 12:34:54 -0600
Newsgroup: bit.listserv.vmesa-l
"Schuh, Richard" wrote:
Yeah, but 3090 memory was not ferrite core, was it? IIRC, it was much
cheaper and more reliable. I wasn't privy to the bean-counting
specifics, but the rumored cost of the LCS storage on our 360 class
machines was in the neighborhood or $2.5-3M per 2MB unit. And they were
real core - you could look through the glass panels and see the
individual planes of wires and doughnuts. The stuff was not reliable, so
we had 3 boxes in order to always have 1 available for the production
ACP system. There was usually 1 in use, 1 being repaired, and 1 just out
of repair that was on standby. The care and feeding of those animals was
a career.
small spill-over from bit.listserv.ibm-main mentioning extended store,
3090 memory, 360 memory, 360 LCS and a couple other memory related
topics
http://www.garlic.com/~lynn/2006r.html#34 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#35 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#37 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#39 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#40 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#42 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006r.html#43 REAL memory column in SDSF
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: bandwidth of a swallow (was: Real core)
Date: Thu, 12 Oct 2006 06:49:06 -0600
Newsgroup: bit.listserv.vmesa-l, alt.folklore.computers
Paul B. Nieman wrote:
In the early 1990's we consolidated a data center from Sydney into
Philadelphia. We used SYBACK to do a full dump of specific (most)
minidisks to tape and shipped the tapes. We then performed daily
incrementals to disk, and sent the incrementals via RSCS, via a 9600
baud line at most. I think we had a 9600 baud line that was shared
for RSCS and VTAM traffic, but the telecom part wasn't mine to worry
over. Each minidisk intended to move was a separate file and sent via
SENDFILE. There were service machines written to send and receive
them. I think the first incrementals arrived before the tapes. In
any case, we kept track of different day's incrementals for a whole
week and applied them as they finished arriving. The line was kept
very busy and watched closely, but it was easy to restart if it
dropped.
Our actual cutover the following weekend went fairly quickly and met
whatever target we had, which I certainly think wasn't enough to allow
for backing up, shipping, and applying the tapes.
earlier post in start of this thread:
http://www.garlic.com/~lynn/2006s.html#16 memory, 360 lcs, 3090 extended store, etc
in the later part of the mid-70s, one of the vm370 based commercial
time-sharing services had datacenter on the east coast and put in
datacenter on the west coast connected via 56kbit link.
the had enhanced vm370 to support process migration between
loosely-coupled machines in the same datacenter cluster ... i.e. for
one thing, as they moved to 7x24 worldwide service ... there was no
window left for doing preventive maintenance. process migration
allowed them to move everything off a complex (that needed to be taken
down for maint). the claim was that they could even do process
migration over the 56kbit link ... modulo most of the file stuff
having been replicated (so that there wasn't a lot needing movement in
real time).
misc. past posts mentioning vm time-sharing service
http://www.garlic.com/~lynn/subtopic.html#timeshare
they had also implemented page mapped filesystem capability with lots
of advanced bells and whistles ... similar to the cms page mapped
filesystem stuff that i had originally done in the early 70s for cp67.
http://www.garlic.com/~lynn/subtopic.html#mmap
which also included a superset of the memory segment stuff ... a small
subset was later released as DCSS
http://www.garlic.com/~lynn/subtopic.html#adcon
for other drift ... as mentioned before ... the internal network was
larger than the arpanet/internet from just about the beginning until
around sometime mid-85. misc. posts mentioning internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet
one of the issues was what to do about JES2 nodes on the internal
network. one of the issues was that relatively trivial changes in JES2
headers between releases would precipitate JES2 (& MVS) system
crashes. for that reason (and quite a few others), JES2 nodes were
pretty well limited to a few boundary nodes. A library of vnet/rscs
line drivers grew up for JES2 that supported a cannonical JES2 header
format ... and the nearest VNET/RSCS node would have the specific
line-driver started that would make sure that all JES2 headers sent to
the JES2 system ... met the requirements of that specific JES2
version/release. Sporadically, there were still some (infamous) cases
where JES2 systems on one side of the world would precipitate JES2
systems on the other side of the world to crash (one particular well
known case was JES2 systems in san jose causing JES2/MVS systems in
hursley to crash). misc. past posts mentioning hasp &/or jes2
http://www.garlic.com/~lynn/subtopic.html#hasp
Another scenario was there was some work to do load-balancing offload
between STL/bld90 and Hursley around 1980 (since they were offset by a
full shift). the test was between two jes2 systems (carefully checked
to be at compatible release/version) ... over a double-hop 56kbit
satellite link (i.e. up from west coast to satellite over the us, down
to the east coast, up to satellite over the atlantic, down to
UK). JES2 couldn't make connection ... but all error indicators were
clean. So finally it was suggested to try the link between two vnet
systems. The link came up and ran with no problem.
The person overseeing the operations was extremely sna/vtam
indoctrinated. So the first reaction was what ever caused the problem
went away. So it was time to switch it back between JES2 ... it didn't
work. Several more switches were made ... always ran between VNET,
never ran between JES2. The person overseeing the operation finally
declared that the link actually had severe error problems but the
primitive VNET drivers weren't seeing them ... and only the advanced
VTAM error analysis was realizing there was lots of errors.
it turned out the problem was with the double-hop satellite roundtrip
(four hops, 44k miles per hop, 22k-up, 22k-down) propagation delay ...
which VNET tolerated and vtam/jes2 didn't (not only was the majority
of the internal network not jes2 ... it was also not sna/vtam)
From: lynn@garlic.com
Newsgroups: alt.folklore.computers
Date: 12 Oct 2006 08:33:07 -0700
Subject: IDC: Virtual machines taking over the world
Virtual machine software market grew 67% in 2005: IDC
http://www.crn-india.com/breakingnews/stories/67448.html
IDC: Virtual machines taking over the world
http://arstechnica.com/news.ars/post/20061011-7966.html
the new, (40yr) old thing from the cambridge science center, 4th flr,
545 technology sq.
http://www.garlic.com/~lynn/subtopic.html#545tech
some more detailed history from Melinda Varian's paper, VM and the VM
Community: Past, Present, and Future, at
http://www.princeton.edu/~melinda/
Refed: **, - **, - **
From: lynn@garlic.com
Subject: Re: Very slow booting and running and brain-dead OS's?
Date: Thu, 12 Oct 2006 16:18:40 -0700
Newsgroups: alt.folklore.computers
Andrew Swallow wrote:
Multi-core CPUs will bring this sort of knowledge back. We are
talking multi-user systems with weak memory protection.
most of the recent chip conferences ... and several more recent press
releases are about how application software isn't capable of taking
advantage of the multi-core chips .... and that significant changes in
(especially application) programming paradigm is required in order to
adequately support the levels of parallelization. chips with 2, 4, 8
cores and 80 cores being projected in the not too distant future
a few posts this year mentioning multi-core and/or parallelization
http://www.garlic.com/~lynn/2006.html#14 Would multi-core replace SMPs?
http://www.garlic.com/~lynn/2006.html#16 Would multi-core replace SMPs?
http://www.garlic.com/~lynn/2006b.html#22 Would multi-core replace SMPs?
http://www.garlic.com/~lynn/2006b.html#40 another blast from the past ... VAMPS
http://www.garlic.com/~lynn/2006n.html#44 Any resources on VLIW?
http://www.garlic.com/~lynn/2006p.html#0 DASD Response Time (on antique 3390?)
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: real core
Date: Fri, 13 Oct 2006 06:07:33 -0600
Newsgroup: bit.listserv.vmesa-l
Tom Duerbush wrote:
So I guess the question I'm wondering...
How many others have shipped dumps, online, back before high speed
Internet connections?
re:
http://www.garlic.com/~lynn/2006s.html#16 memory, 360 lcs, 3090 extended
store, etc
http://www.garlic.com/~lynn/2006s.html#17 bandwidth of a swallow (was:
real core)
we had done HSDT (high speed data transport) project
http://www.garlic.com/~lynn/subnetwork.html#hsdt
in the 80s ... with high-speed backbone connected to the internal
network.
http://www.garlic.com/~lynn/subnetwork.html#internalnet
in the late 80s, the backbone was used to ship chip designs to
high-speed hardware logic simulators/checkers located in san jose
area. this was claimed to have contributed to helping bring in
rios/power chipset a year early. recent post discussinglsm&eve
logic simulators (and using HSDT backbone to transport chip design):
http://www.garlic.com/~lynn/2006r.html#11 Was FORTRAN buggy?
we were also interested in participating in nsfnet-1 backbone
(which could be considered the operational precurser to the modern
internet). we weren't allowed to bid ... but did get an technical
review, one of the conclusions was what we had running and operational
was at least five years ahead of all the nsfnet-1 bids (RFP
responses) to build something new. slightly related
http://www.garlic.com/~lynn/internet.htm#0
and
http://www.garlic.com/~lynn/2002k.html#12 nsfnet program announcement
http://www.garlic.com/~lynn/2000e.html#10 nsfnet award announcement
for other drift, in the early days of rex (rexx), i wanted to
demonstrate that rex wasn't just another batch command processor
(exec, exec2) but could be used to implement very complex
application. I chose the vm problem/dump analyzer ... which was a
fairly large application written in assembler. i wanted to demonstrate
that in 3 months working half-time, i could implement in rex something
that had ten times the function and ten times the performance of the
existing assembler implementation. the result was dumprx
http://www.garlic.com/~lynn/subtopic.html#dumprx
which could be used to analyze a dump interactively ... even over the
internal network w/pvm (terminal emulation) ... w/o having to actually
ship the dump. part of dumprx was library of automated analysis
scripts ... the results could be saved and restored; aka you could run
the automated analysis scripts ... that batched the most common
sequence of manual analysis processes.
the library of batched analysis routines effectively automated most of
the most common (manual) analysis procedures (examined storage for a
broad range of failure signatures).
Refed: **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: Re: Very slow booting and running and brain-dead OS's?
Date: Fri, 13 Oct 2006 13:39:10 -0700
Newsgroups: alt.folklore.computers
Tim Bradshaw wrote:
It seems to me that there are two obvious commercially-important uses
for these systems.
Firstly, there is a significant market for reasonably large SMP
machines already, and that market should love multi-core processors as
it reduces their costs (or equivalently makes their machines larger).
Secondly virtualisation is very fashionable right now (I know it's
hardly a new idea), and I should think it's an application which can
make use of as many cores as you want. I suspect most large
datacentres are absolutely stuffed with awful old x86 boxes using up 8u
of terribly expensive rack space and running some antique version of
Windows / Linux / etc but which can't be turned off because they
provide some critical service which no-one knows how to reimplement.
Virtualising n of those onto a single n+a-few-core multicore /
multichip system ought to be a big win (albeit an admission of defeat
in software engineering terms).
I guess the issue with both of these is whether an n-core chip can
provide enough bandwidth to off-chip resources to keep all the cores
busy. I presume they can, or will be able to.
refs:
http://www.garlic.com/~lynn/2006q.html#32 Very slow booting and running and brain-dead OS's?
http://www.garlic.com/~lynn/2006r.html#41 Very slow booting and running and brain-dead OS's?
http://www.garlic.com/~lynn/2006s.html#7 Very slow booting and running and brain-dead OS's?
http://www.garlic.com/~lynn/2006s.html#19 Very slow booting and running and brain-dead OS's?
cp67 virtual machines are nearly 40 years old. the initial
implementation was cp40 on a 360/40 modified with custom virtual
memory hardware ... this morphed into cp67 in 1967 when 360/67 became
available .... done at cambridge science center, 545 tech sq
http://www.garlic.com/~lynn/subtopic.html#545tech
when lincoln labs discountinued their 360/67 multiprocessor, cambridge
upgraded their single processor 360/67 by calling up the moving
company and telling them that instead of taking lincoln's machine back
to the factory ... instead it was to be moved to the science center.
charlie then did a lot of work on fine-grain locking for cp67
multiprocessing support. out of this work, charlie invented
compare&swap instruction (instruction name chosen because CAS are
charlie's initials). this was shipped in 370 processors. initially
there was a lot of push back claiming that 370 didn't need another
multiprocessor specific instruction (test&set carried over from 360
should be good enuf). to get the instruction into 370, additional
(non-multiprocessor specific) uses needed to be defined for the
instruction. thus was born the descriptions of various uses by
multi-threaded application code (whether or not it happened to be
running on single processor or multiprocessor). misc. past posts
mentioning multiprocessor, compare&swap, etc
http://www.garlic.com/~lynn/subtopic.html#smp
part of the issue is the ever increasing memory latency ... the
absolute memory latency hasn't change significantly ... but with the
declining bus cycle time, the memory latency measured in number of
processor instruction cycles has gone way up.
caches have been used to compensate for memory latency ... as has
wider memory bus ... moving more data per memory bus cycle.
out-of-order instruction execution has been used to try and keep
execution busy when there are instructions stalled waiting for memory
bus. multithreading is also method trying to keep the processor
execution units busy .... in the face of instruction stalls waiting on
memory
i got somewhat periphrally involved with an early multi-threaded
effort involving 370/195 (that never actually shipped). 370/195 was
pipelined and optimally peaked around 10mips. however, branches
drained the pipelined (no branch prediction, speclutive execution,
etc). the frequency of branches in most codes limited 370/195 to
around 5mips. the hyperthreading proposal was to create emualted smp
machine with dual i-streams, dual registers, etc. There was only
standard pipeline and execution units ... instructions and registers
in the pipeline would have a one bit tag added, indicating which
instruction stream they were associated with. If standard codes and
branch frequency resulted in running the execution units at half
busy/capacity .... then possible dual instruction stream could keep
the units operating at near peak capacity.
with large number of cores, sharing some common cache .... one
programming paradigm change implies lots of parallel multi-threaded
operation (the type of stuff that was raised in the early compare&swap
instruction justification) .... attempting to maximize the aggregate
mip rate per number of bytes transferred over the memory bus.
Refed: **, - **, - **
From: lynn@garlic.com
Subject: Re: Why these original FORTRAN quirks?
Date: Sat, 14 Oct 2006 05:28:18 -0700
Newsgroups: alt.folklore.computers
i don't remember any bugs ... although beginning fortran was first
programming course some 40 yrs ago ... card decks and compiled/run on
709.
however, person involved in doing the 370/145 apl/cms microcode assist
at the palo alto science center was also responsible for the internal
"fortran q" enhancements ... eventually released in the product as
fortran hx.
misc. past references:
http://www.garlic.com/~lynn/2001g.html#20 Golden Era of Compilers
http://www.garlic.com/~lynn/2002g.html#1 WATFOR's Silver Anniversary
http://www.garlic.com/~lynn/2002j.html#5 HONE, xxx#, misc
http://www.garlic.com/~lynn/2003b.html#52 Disk drives as commodities. Was Re: Yamhill
http://www.garlic.com/~lynn/2004m.html#6 a history question
when we were doing ecps microcode assist originally for 148 (follow-on
to 145) ... we had modified the kernel to time-stamp a lot of
entry/exits ... which resulted in narrowing initial candidates for
kernel machine code migration to microcode
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist
he did a psw/instruction-address sampler microcode modification on the
370/145 ... i.e. microcode routine that would wake up periodically and
use the current instruction address to index a storage use frequency
counter (i.e. divide address by 64, multiple by four, add to base
table address to index a full word counter ... and increment the value
at that location).
later he also did work on pli optimization.
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: Re: Why magnetic drums was/are worse than disks ?
Date: Sat, 14 Oct 2006 06:58:16 -0700
Newsgroups: comp.arch
Stephen Fuld wrote:
Well, one area that disk packs had (at least at first) that drums didn't was
interchangability. That is, you could have more disk packs than drives and
load the packs as needed, sort of like having more tape reels/cartridges
than tape drives. This could give the illusion of more storage on-line than
was really available. Of course, as technology progressed, this idea had to
give way to increased density.
i think part of 2303/2301 drums were getting all the heads aligned on
the surface. 2301 was sort of a 2303 but read/wrote four heads in
parallel (and therefor had four times the data transfer rate). 2301
was used on lots of 360/67 cp67 systems for virtual memory paging.
various recent posts mentioning fixed head 2301/2303 drums
http://www.garlic.com/~lynn/2006.html#2 Average Seek times are pretty confusing
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006.html#41 Is VIO mandatory?
http://www.garlic.com/~lynn/2006c.html#46 Hercules 3.04 announcement
http://www.garlic.com/~lynn/2006i.html#27 Really BIG disk platters?
http://www.garlic.com/~lynn/2006q.html#32 Very slow booting and running and brain-dead OS's?
http://www.garlic.com/~lynn/2006r.html#23 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#30 50th Anniversary of invention of disk drives
in the 70s, 2301/2303 was replaced with 2305 fixed head disks .. (that
had three times the capacity of the 2301 but about the same transfer
rate).
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: Re: Curiousity: CPU % for COBOL program
Date: Sat, 14 Oct 2006 09:14:55 -0700
Newsgroups: bit.listserv.ibm-main
Larry Bertolini wrote:
I'm looking at this from the "I have never considered..." angle.
Times have changed, since your formed that opinion.
Consider two factors:
1. The trend to machines with fewer, faster processors.
The typical COBOL program is "single-threaded", and
can exploit only one CPU. If you have a 6-way, a single
COBOL program is unlikely to use more than 17% of the CPU;
if you have a 1-way (presumably 6x faster) it may use >95%,
under certain conditions.
2. Faster I/O subsystems. If you have a COBOL program that does
VSAM processing, it doesn't use much CPU while it's waiting for
disk I/O. But if those waits are very short, the program will
run faster, and consume more CPU seconds per wall-clock minute.
although the next stage might be what the risc/ciscs chips are running
into ... going to multi-cores per chip.
a few years ago, i had to look at an extremely large (several hundred
thousand statement) cobol applciation that represented an extremely
significant corporate workload (that ran on large number of mainframe
systems)
in the early to mid-70s at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech
we commoningly used three techniques
• hot-spot sampling
• modeling
• multiple regression analysis
and found that sometimes one technique would identify things that the
other two techniques couldn't
an example of hot-spot sampling is mentioned in this recent post about
determining what part of kernel machine language should be dropped
into microcode (part of a longer thread that also discusses needing
programming paradigm changes to support parallel operation)
http://www.garlic.com/~lynn/2006s.html#21 Very slow booting and running and brain-dead OS's
the modeling work evolved into a performancing modeling tool
(performance predictor) available on HONE (world-wide support system
for marketing, sales, and field people)
http://www.garlic.com/~lynn/subtopic.html#hone
that sales people could use to ask what-if questions about customer
workload and configuraiton (i.e. what happens if the worload changes
or what happens if more real storage is added, etc). much of this
work was also basis for capacity planning ... for some drift.
http://www.garlic.com/~lynn/subtopic.html#bench
in the mid-90s the rights to a much evolved descendent of this
modeling tool was acquired by somebody in europe ... who ran it thru
an APL->C language converter and was using it in mainframe consulting
businesses at high-end
the particular large cobol application had been extensively analyzed
with hot-spot analysis and this later generation performance modeling
tool with some amount of success finding areas that could be
recoded/restructure for improving thruput. however, it was felt that
there must be a lot of opportunity still left (the application had
evolved over a couple decades and there was a feeling that it was now
significantly slower than it was when it first started).
i suggested that multi-regression analysis be used on internal
application activity counters. the result was that it identified some
operation that accounted for something like 20 percent of total
activity (but invoked executable code in very convoluted way that
wasn't easily identifiable using the other two mechanisms). with that
information, it turned out it was fairly straight-forward to
restructure that particular operation and gain another 14percent
improvement (running across a fairly large number of max'ed out
mainframe processor configurations)
however, there has been the issue that many of these large serial
batch operations are going to have to be reworked for much higher
degree of parallel operation.
misc. past posts mentioning multiple regression analysis technique
http://www.garlic.com/~lynn/2002l.html#62 Itanium2 performance data from SGI
http://www.garlic.com/~lynn/2005d.html#6 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005k.html#17 More on garbage collection
http://www.garlic.com/~lynn/2005n.html#18 Code density and performance?
http://www.garlic.com/~lynn/2006f.html#22 A very basic question
http://www.garlic.com/~lynn/2006g.html#4 The Pankian Metaphor
http://www.garlic.com/~lynn/2006o.html#23 Strobe equivalents
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VM SPOOL question
Date: Sun, 15 Oct 2006 06:44:14 -0600
Newsgroups: bit.listserv.vmesa-l, alt.folklore.computers
originally cp67 had everything in the kernel, booted and fixed in real
memory, there were a pre-allocated fix number of save areas for kernel
linkage (making it slightly easier to identify everything going on
from a dump ... so all saveareas were in contiguous area of storage),
and total kernel dynamically allocated working storage (all the kernel
control blocks, virtual i/o structure, virtual memory, working
storage, etc) could increase by making calls to paging supervisor
as undergraduate, i did a lot of work on dynamic adaptive scheduling
and graceful degradation with increasing work load.
increasing work load ... could exhaust the pre-allocate kernel linkage
save areas ... so i had to make change to allow for kernel linkage
save areas to dynamically increase (decrease) in much the same way the
rest of kernel dynamically allocated storage could
increase/decrease. this became part of the distributed cp67 kernel
there was a lot of stuff in the cp67 kernel that was relatively low
useage ... like various commands, and with increasing work load, there
was lot more pressure on available real storage ... a 786k 360/67, 64
pages per 256k ... might only have 110-120 pages after fixed kernel
requirements; being able to "page-out" low-useage kernel components
might pick up 15-20percent real storage for workload. this didn't ship
in the standard kernel until vm370.
there was an issue with the free storage manager doing a generalized
call to the paging supervisor for additional working storage. the
paging supervisor could sometimes select a modified virtual memory
page for replacement ... this would require scheduling a page i/o
write for the page and waiting for the i/o to complete before making
it available for kernel use (during that period the system would
sometimes crash because of lockup and exhausted working storage). i
created a special page replacement interface for the kernel storage
manager ... that would look for any non-changed/non-modified page for
replacement (eliminating any delay in extending kernel working storage
by scavenging paging memory). this went out in standard cp67 product.
for a little drift ... also as an undergraduate i completely redid the
page replacement algorithm ... implementing global LRU based on page
reference bits ... lots of past postings discussing page replacement
algorithms
http://www.garlic.com/~lynn/subtopic.html#wsclock
lots of these factors contribute to what appears to be amount of real
memory that is associated with the kernel ... and therefor the amount
of spool space that may be required for containing a image "dump" of
all the associated kernel real storage.
for other topic drift ... lots of past postings mentioning problem
failure/diagnostic
http://www.garlic.com/~lynn/subtopic.html#dumprx
much, much later ... i had an issue with the aggregate thruput that a
single virtual machine could get out of the spool file interface. part
of the issue was that spool buffer transfers were synchronous
... during which time the virtual machine didn't process.
recent posts in this n.g.
http://www.garlic.com/~lynn/2006s.html#17 bandwidth of a swallow
http://www.garlic.com/~lynn/2006s.html#20 real core
mentioning HSDT effort. part of this was vnet/rscs driving multiple
HYPERchannel links ... some channel speed links between machines in
the same machine room (couple mbytes/sec) and a number of full duplex
T1 links (about @300kbytes/sec aggregate per link) ... creating a
requirement for several mbytes/sec aggregate thruput.
the synchronous nature of the spool interface limited vnet/rscs to
something like 5-10 4k spool buffers/sec (depending on other load for
the spool system) ... or 20kbytes/sec under most loads to possibly max
of 40kbytes/sec. HSDT needed aggregate spool thruput closer to 100
times that.
so my effort was to move most of the spool function into a virtual
address space, completely recode it in vs/pascal, and provide
significant additional asynchronous behavior and other thruput
enhancements (in order to increase aggregate thruput by two orders of
magnitude) . recent post discussing the changes
http://www.garlic.com/~lynn/2006s.html#7 Very slow booting and running and brain-dead OS's
part of the implementation running spool function in virtual address
space was taking advantage of the page map interface that i had done
originally in the early 70s for cp67 cms page mapped filesystem
http://www.garlic.com/~lynn/subtopic.html#mmap
also part of HSDT backbone was doing rfc1044 support (which shipped in
the product) for the mainframe tcp/ip implementation (also originally
written in vs/pascal). the base tcp/ip support would consume nearly a
full 3090 processor getting aggregate 44kbytes/sec thruput. in some
tuning/testing at cray research, between 4341 clone and cray
... rfc1044 was getting sustained channel interface thruput
(1mbyte/sec) using only modest amount of the 4341 clone processor.
http://www.garlic.com/~lynn/subnetwork.html#1044
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why these original FORTRAN quirks?
Newsgroups: alt.folklore.computers
Date: Mon, 16 Oct 2006 06:19:13 -0600
jmfbahciv writes:
Yes.
I loved when computed GOTOs showed up. The logic flow became
so easy. Programming based on two-branch, yes/no, flow charts
could get very awkward.
related comments in another thread:
http://www.garlic.com/~lynn/2006p.html#1 Greatest Software Ever Written?
http://www.garlic.com/~lynn/2006p.html#4 Greatest Software Ever Written?
360 assembler could have condition setting instruction followed by one
or more branches. 360 condition code is two bits ... so could have
four possible values. branch condition instructions used four bits
... so could setup to take branch on one or more possible condition
code values (or "no-op" instruction)
from my q&d conversion of green card ios3270 to html
http://www.garlic.com/~lynn/gcard.html#2 Extended Branch Mnemonics
... assembler instruction branch mnemonics that generate specific
branch "mask" conditions.
and condition code settings mapped to conditional branch mask
http://www.garlic.com/~lynn/gcard.html#8 Condition Codes Settings
i.e.
CC branch mask
-- -----------
00 1000
01 0100
10 0010
11 0001
for some instructions ... it would be possible to program for four
different code paths taken based on the instruction condition code
setting (as opposed to simple two-way).
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why these original FORTRAN quirks?
Newsgroups: alt.folklore.computers
Date: Mon, 16 Oct 2006 06:42:08 -0600
jsavard writes:
There *was* another reason for a three-way branch, though, besides
having a CAS instruction.
If one assumes the programmer will ensure the expression in the IF
statement doesn't overflow, a three way branch covers all the cases
with one form of statement. There is no need to define a family of
operators - .EQ. .LT. .NE. .GT. .LE. and .GE. - to cover six different
comparison tests.
post about four possible code paths
http://www.garlic.com/~lynn/2006s.html#26 Why these original FORTRAN quirks?
for if/then/else ... one wonders if it was those 2-value, true/false
logic/philosophy classes, truth tables, etc ...
for some drift ... 3-value logic posts
http://www.garlic.com/~lynn/2003g.html#40 How to cope with missing values - NULLS?
http://www.garlic.com/~lynn/2003g.html#41 How to cope with missing values - NULLS?
http://www.garlic.com/~lynn/2004l.html#75 NULL
http://www.garlic.com/~lynn/2005.html#15 Amusing acronym
http://www.garlic.com/~lynn/2005i.html#35 The Worth of Verisign's Brand
http://www.garlic.com/~lynn/2005m.html#19 Implementation of boolean types
http://www.garlic.com/~lynn/2005r.html#15 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005t.html#20 So what's null then if it's not nothing?
http://www.garlic.com/~lynn/2005t.html#23 So what's null then if it's not nothing?
http://www.garlic.com/~lynn/2005t.html#33 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2006e.html#34 CJ Date on Missing Information
http://www.garlic.com/~lynn/2006q.html#22 3 value logic. Why is SQL so special?
http://www.garlic.com/~lynn/2006q.html#23 3 value logic. Why is SQL so special?
http://www.garlic.com/~lynn/2006q.html#29 3 value logic. Why is SQL so special?
From: Anne & Lynn Wheeler <lynn@garlic.com>
Newsgroups: bit.listserv.ibm-main
Subject: Re: Storage Philosophy Question
Date: Mon, 16 Oct 2006 09:36:21 -0600
R.Skorupka@ibm-main.lst (R.S.) writes:
1. DASD mirroring does not prevent you against errors in data. Errors
made by human, software bug, etc.
2. Campus area seems to be too small to talk about serious DR
centre. Too short distance. Numerous disaster types could spread both
locations.
3. There is no real protection (with excpetions to NORAD etc.) against
terrorist attacks. They can attack two locations at the same time, the
distance is irrelevant.
the early 80s ... there were some studies that chose 40 miles as a
minimum number ... although you still have to look at common failure
modes ... like 40 miles along the same river (flood plain) that would
flood both locations. some places have extra redundancy with more than
single replication.
when we were doing ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp
we coined the terms disaster survivability and geographic
survivability
http://www.garlic.com/~lynn/subtopic.html#available
we talked to a number of operations about their experiences.
one operation had carefully chosen a datacenter metropolitan bldg for
(physical) diverse routes ... two different water mains on opposite
sides of the bldgs, two power feeds from different power substations
on opposite sides of the bldg., four telco feeds entering from four
physical sides, from four different central offices.
their datacenter went down when they had a transformer blow and the
bldg. had to be evacuated because of PCB contaimination.
some of this gets into other kinds of threat models ... misc.
postings mentioning vulnerabilities, threats, exploits, fraud, etc
http://www.garlic.com/~lynn/subintegrity.html#fraud
and/or assurance
http://www.garlic.com/~lynn/subintegrity.html#assurance
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why these original FORTRAN quirks?
Newsgroups: alt.folklore.computers
Date: Mon, 16 Oct 2006 17:18:28 -0600
Peter Flass <Peter_Flass@Yahoo.com> writes:
I used this a few times, but I try to make sure the code is bracketed
with "keep together" lines and lots of comments. It seems a little
error-prone to me.
re:
http://www.garlic.com/~lynn/2006s.html#26 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2006s.html#27 Why these original FORTRAN quirks?
take for example sio/siof (start i/o) instruction
http://www.garlic.com/~lynn/gcard.html#8.4 Condition Codes - Input/Output Instructions
from above
SIO, SIOF Successful CSW stored Busy Not operational
00 01 10 11
1000 0100 0010 0001
... something like
SIO
BC 8,success wait for completion
BC 4,cswstored analyze status
BC 2,busy requeue and wait to redrive
BC 1,notthere error, not there
• can't get here since all possible conditions have been used
...
note that busy/10 was typically subchannel busy. however, in cswstored/01
you could also get a BUSY status.
http://www.garlic.com/~lynn/gcard.html#6 Channel Status Word
from above ... SM+BUSY would indicate control unit busy, BUSY by
itself would indicate device busy. However, with the introduction of
disk string-switch, it was possible that the string-switch could be
busy ... so they had to make BUSY (by itself) serve dual purpose for
both device busy and string-switch busy.
then there was a condition called "short control unit busy" ... i.e
SM+BUSY+CUE ... on initial selection, the control unit was busy, but
before the handshaking had completed, the control unit became free.
the standard process for short control unit busy was to immediately
redrive the operation.
however, when i was trying to drop bullet proof i/o supervisor into
the disk engineering and product test labs
http://www.garlic.com/~lynn/subtopic.html#disk
... one of the issues was flakey control unit that always presented
SM+BUSY+CUE ... and unless you were prepared ... things could get in
an endless loop. sometimes the code might skip the "BC 4,cswstored"
instruction and let execution fall thru into the initial csw stored
analysis
SIO
BC 8,success wait for completion
BC 2,busy requeue and wait to redrive
BC 1,notthere error, not there
• falls thru into cswstored analysis
...
"not-there" could be misconfiguration. however, it could also be
operators playing around with multi-channel switches on things like
tape drives ... resetting switches so that a tape drive would get
manually reconfigured to a different processor complex.
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why magnetic drums was/are worse than disks ?
Newsgroups: comp.arch
Date: Tue, 17 Oct 2006 05:37:34 -0600
"Del Cecchi" <delcecchiofthenorth@gmail.com> writes:
When I wrote "two heads per platter", I
wasn't trying to suggest that the heads
were on the same side of the platter.
I was referring to one head on either
side of the platter, where both sides
of a platter are covered with magnetic
film.
re:
http://www.garlic.com/~lynn/2006s.html#23 Why magnetic drums was/are worse than disks ?
360 2303/2301 were nearly identical drums ... with 2301 read/writing
four heads in parallel (with four times the transfer rate of 2303)
the 370 replacement for 2303/2301 was the 2305 fixed-head disk. there
were two models ... the larger capacity had about the same transfer
rate as the 2301 and three times the capacity. there was another model
with half the capacity ... same number of heads but half the
rotational delay ... i.e. instead of one head per track, there were
two heads per track offset by 180 degrees (but only one head
read/write at a time).
a lot of the 2305s were used for virtual memory paging ... and
operating system optimized for doing full-track transfers ... as a
result, the larger capacity was more important than cutting the
avg. rotational delay in half.
later there were some number of emulated 2305s (referred to as 1655)
made from memory chips that had failed some number of standard memory
tests. recent post discussing 1655s
http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
and from not so long ago and far away ... early variation on
attempting to get higher recording densitites and/or transfer rates.
in the following, servo feedback tracking controls per arm (head)
would have fine-grain servo positioning of the active head over the
platter being read/written.
there had been some discussion of doing parallel read/writes of all
heads on a disk ... but as physical dimensions became smaller ... it
would require that different heads on different surfaces have
simulataneous, independent servo feedback tracking (difficult if they
are all on the same physical structure).
From: wheeler
Date: Sun, 22 Nov 1987 09:44:56 PST
Subject: DASD operational characteristics;
Recent article quotes IBM Almaden as saying that they have come up
method for increasing DASD density by a factor of 50. Several years
ago, DASD engineers were sure that they could go to a factor of 100
over 3380. On 3380, the inter-track gap was 20 track widths ... with
servo feedback tracking controls on the arm ... 3380s could go to
single track-width gaps (increase by factor of 10). Vertical
recording techniques can give a bit density of another factor of 10
over current technologies. This accounts for a factor of 100 over
3380s. Since that time, "double-density" 3380Es have cut the
inter-track gap to 10 track-widths.
In my CDROM review, there was at least two or three japanese companies
that are offering vertical recording on which they place CDROM-type
capacities on 5in floppies (i.e. multi-hundred mbytes).
The increase in DASD capacity by 100 (or 50) has a severe impact
on arm loading, access. One way of characterizing data is calculate
the number of times there is some access to that data per second.
That calculation can be prorated per megabyte. The resulting
figure gives a number that says
for "such & such" a configuration/load or "such & such" a number
of accessing programs/users ... specific data has an access
rate of "N read/writes per second per megabyte".
Such a data profile characterization usually indicates for many classes
of data, it is not possible to put more than a hundred megabytes of
data on a DASD (regardless of the available space) w/o saturating
arm access capacity and degrading performance.
Vertical recording has a couple implications that lead towards
requiring full-track I/O with full-track buffers co-located with the
drive. Given that the drive is spinning at the same speed, then there
is 10* as much data passing under the heads in the same unit time ...
i.e. the data transfer rate between head and disk increases by a
factor of 10. If a track currently contains 500kbytes and transfers
data at 20mbit/sec, vertical recording will make that 5mbytes/track
and 200mbit/sec transfer rate.
... snip ... top of post, old email index
and another proposal for significantly optimizing inter-track gaps and
servo-tracks per data tracks ... however this has the same physical
head (and servo feedback mechanism) read/write 16 tracks in parallel.
From: wheeler
Date: Wed, 30 Dec 1987 07:46:14 PST
xxxxxxx wants me to go to ykt with him week after next. He wants to
talk to yyyyyy about doing a disk head with 16+2 r/w surfaces. There
would be two r/w surfaces on the outer edges to handle servo track
information with 16 data r/w surfaces between them. Data would be
transferred in parallel over the 16 r/w data areas. Head would format
a surface by writing servo tracks and 16 data tracks at the same time,
then move to the next track grouping. Surface would have one servo
track for every 16 data tracks (with head nominally overlapping two
servo tracks). xxxxxx talks about gigabit transfer rate and possibly
gigabyte storage on 5in surface.
... snip ... top of post, old email index
some number of posts mentioning working with the disk engineers
in bldg. 14
http://www.garlic.com/~lynn/subtopic.html#disk
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why magnetic drums was/are worse than disks ?
Newsgroups: comp.arch
Date: Tue, 17 Oct 2006 05:56:35 -0600
"robertwessel2@yahoo.com" <robertwessel2@yahoo.com> writes:
Certain models of IBM 3340 did the same thing.
3330s had 20 surfaces and 20 read/write heads on the arm ... but only
19 "data" heads. the 20th surface was used for encoding positional
information. compared to the 360 2311/2314 disks, the "370" 3330s
introduced a new command structure called rotational positional
sensing (RPS).
normal dasd/disk i/o command sequence positioned the arm and then
reserved tied-up channel, controller and disk "searching" for the
desired record to be read/written. the new RPS sequence allowed for
careful programming to approximately positioning the disk rotation
before starting the record search operation.
this was left over from the original 360 trade-off ... where (excess)
i/o capacity was traded off against very scarce real memory resource.
i/o command programming and all arguments for i/o command programming
were stored in processor memory and (constantly) accessed by
channel/controller/device. most disk and filesystem format structures
were kept on disk ... as opposed to be cached in processor storage.
i/o command programming could specify search argument for some record
identification (like member of program library) and turn the disk
loose to search for it. recent post about multi-track search
operations
http://www.garlic.com/~lynn/2006s.html#15 THE on USS?
lots of past posts mentioning DASD operational characteristics and
multi-track search trade-off characteristics
http://www.garlic.com/~lynn/subtopic.html#dasd
i've done a q&d conversion of old green card ios3270 file to html
http://www.garlic.com/~lynn/gcard.html
http://www.garlic.com/~lynn/gcard.html#12 channel command word
http://www.garlic.com/~lynn/gcard.html#26 DASD command codes
http://www.garlic.com/~lynn/gcard.html#26.1 CKD command codes
http://www.garlic.com/~lynn/gcard.html#26.4 RPS sector formulae
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why magnetic drums was/are worse than disks ?
Newsgroups: comp.arch
Date: Wed, 18 Oct 2006 07:04:56 -0600
Benny Amorsen <benny+usenet@amorsen.dk> writes:
What about simply having two entirely independent arms, both capable
of reaching all tracks? That could potentially cut rotational latency
in half. Yay for a virtual 30000rpm disk...
it was called 2305-1 ... fixed head disk with two pairs of heads per
track, offset by 180degrees ... it had the same number of heads as the
2305-2 ... but only half the data capacity.
picture of 2301 drum
http://www.columbia.edu/acis/history/drum.html
picture of 2305 fixed head disk (announced 28jan70, withdrawn 30jan80):
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_2305.html
note in the above, it mentions that 2305-1 has half the capacity and
half the (rotational delay) access time of 2.5milliseconds (compared
to 2305-2) it also says that it has twice the data transfer rate
(3mbytes/sec) implying that it was transfering data from both heads at
once. however, i don't know any 370 channels that ran at
3mbyte/secs. My understanding was that 2305-1 just transferred data
from whichever head saw the record first.
the later 3380 disks and 3880 disk controller supported 3mbyte/sec
"data streaming" transfer ... and there was a really ugly "speed
matching buffer" project for 3880 disk controller to allow attachment
to 168 (2880 blockmux) channel (running at 1.5mbytes/sec). recent post
discussing 3mbyte/sec "data streaming"
http://www.garlic.com/~lynn/2006g.html#0 IBM 3380 and 3880 maintenance docs needed
the 360/370 channels were limited to 200ft aggregate distance and did
synchronous one byte transfer per channel handshake. going to
3mbyte/sec "data streaming" (and up to 400ft aggregate channel
distance) they relaxed the end-to-end handshake on every byte.
some other drift ... i'm looking for a couple more code names:
?? 2301 fixed-head/track (2303 but 4 r/w heads at time)
?? 2303 fixed-head/track r/w 1-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 disk controller, horizontal microcode engine
Cybernet 3850 MSS (also Comanche & Oak)
Cutter 3880 disk controller, jib-prime (vertical) mcode 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")
recent posts mentioning (370) 2305 fixed head disks (replacement
for the 360 2301/2303 drums)
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006c.html#1 Multiple address spaces
http://www.garlic.com/~lynn/2006c.html#8 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#46 Hercules 3.04 announcement
http://www.garlic.com/~lynn/2006e.html#46 using 3390 mod-9s
http://www.garlic.com/~lynn/2006g.html#0 IBM 3380 and 3880 maintenance docs needed
http://www.garlic.com/~lynn/2006i.html#27 Really BIG disk platters?
http://www.garlic.com/~lynn/2006i.html#41 virtual memory
http://www.garlic.com/~lynn/2006j.html#11 The Pankian Metaphor
http://www.garlic.com/~lynn/2006k.html#57 virtual memory
http://www.garlic.com/~lynn/2006m.html#5 Track capacity?
http://www.garlic.com/~lynn/2006q.html#1 Materiel and graft
http://www.garlic.com/~lynn/2006r.html#23 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#30 50th Anniversary of invention of disk drives
http://www.garlic.com/~lynn/2006r.html#36 REAL memory column in SDSF
http://www.garlic.com/~lynn/2006s.html#23 Why magnetic drums was/are worse than disks ?
http://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than disks ?
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why magnetic drums was/are worse than disks ?
Newsgroups: comp.arch
Date: Wed, 18 Oct 2006 08:45:56 -0600
Anne & Lynn Wheeler <lynn@garlic.com> writes:
note in the above, it mentions that 2305-1 has half the capacity and
half the (rotational delay) access time of 2.5milliseconds (compared
to 2305-2) it also says that it has twice the data transfer rate
(3mbytes/sec) implying that it was transfering data from both heads at
once. however, i don't know any 370 channels that ran at
3mbyte/secs. My understanding was that 2305-1 just transferred data
from whichever head saw the record first.
re:
http://www.garlic.com/~lynn/2006s.html#32 Why magnetic drums was/are worse than disks ?
however, this journal article from 1972: "Channel and direct access
device architecture"
http://www.research.ibm.com/journal/sj/113/ibmsj1103B.pdf
states that the 2880 channel was capable of operating at 3mbyte/sec
(but it wasn't "data streaming" later used for 3380/3880s ... so I
suspect that the maximum cable distance for 3mbyte/sec operation was
significantly reduced) ... so maybe the 2305-1 was reading/writing
from both heads simulataneously (to get 3mbyte/sec)???
you've got two heads off-set 180degrees for the same data. rotational
latency is cut in half (compared to 2305-2), not by spinning twice as
fast ... but using both heads to scan for the same record ... and the
first record that encounters the data, starts the transfer.
the 2301 (drum) got four times the data transfer rate (compared to the
2303) by read/writing four heads in parallel (however, the record data
was syncronized on four tracks in parallel ... so the rotational
latency on the 2301 was the same as 2303, as was the capacity).
if you arrainged pairs of bytes so that they were on opposing sides of
the same track ... then dynamically switch head-pairs between which
was the odd-byte head and which was the even-byte head ... i.e. half
the track would be odd-bytes and the other half of the track would be
even-bytes ... then either head could encounter the start of odd bytes
while the opposing head could encounter the start of the even bytes.
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Basic Question
Newsgroups: talk.politics.crypto
Date: Wed, 18 Oct 2006 11:36:04 -0600
Hagen Ladwig <hal22@t-online.de> writes:
In short, if you use digital signatures for example, they don't
confirm 100% that you signed the document, but with an error
possibility of 10^-30 (I don't know to what parameters and system
this would correspond, it is just a very, very small number).
nominally ... signing a document (as in human signature) implies that
you have read, understood, aggree, approve, and/or authorize.
i've commented before (we had been called in to help word-smith the
cal. electronic signature legislation ... and later the federal
electronic signature legislation)
http://www.garlic.com/~lynn/subpubkey.html#signature
that there appears to be some semantic confusion with the word
"signature" occurring in both the term "digital signature" and the term
"human signature".
nominally digital signature is used to indicate 1) whether something
has been modified and 2) (authenticates) where something originated
a secure hash of something is taken and then encoded with a private
key ... resulting in a "digital signature"
the relying-party/recipient then takes the "something", recomputes the
secure hash, decodes the "digital signature" (with public key
corresponding to private key using in the original encoding) and
compares the two secure hashes. if they are the same, then the
relying-party/recipient can assume:
1) the "something" hasn't been modified since the "digital signature"
2) it originated from the party associated with the public/private
key pair
this can be assumed to be something you have authentication ... the
originating party has (unique) access and/or use of the associated
"private key" (i.e. some specific person is in physical possession of
a unique hardware token containing the only copy of a private key used
for the secure hash encoding).
however, nothing in this process carries the implication that the
originating party has read, understood, aggrees, approves, and/or
authorizes the contents ... just where the contents has originated.
this confusion has given rise to things like possible dual-use attack
scenario.
there are some number of authentication protocols ... where a server
generates and transmits a random number. the client digitally signs
the random number and returns the signature ... for something you
have authentication (random number used as countermeasure
to replay attacks). there is no presumption that the person
associated with the client is even cognizant of the random number
value.
now if the same public/private key pair can be also used in
infrastructures that assume some equivalence to "human signature" (but
failing to provide any additional assurance as to human intent)
.... then you could potentially have an attacker compromising some
server ... and transmitting what appears to be a valid
transaction/contract in lieu of a random number (as part of an
authentication protocol). the digital signature is then automatically
generated w/o any implication of a human have read, understood,
aggrees, approves, and/or authorizes.
the countermeasure to dual-use attack ... is to always require
that there is additional indication as to whether there is any
implication of human signature, human intent, and/or read,
understood, aggrees, approves, and/or authorizes.
another possible countermeasure ... is to NEVER use a
private key in any sort of digital signature based authentication
protocol, where something might be digitally signed that hadn't been
read, understood, agreed, approved, and/or authorized.
this strays into other assurance areas
http://www.garlic.com/~lynn/subintegrity.html#assurance
like the EU FINREAD terminal standard
http://www.garlic.com/~lynn/subintegrity.html#finread
where you have an independent, certified hardware token interface.
the high-assurance, certified terminal is provided with both a
pin-entry interface and display as countermeasure to
1) keyloggers that can capture hardware token pin-entry that can be
used by compromised software to generate operations for the hardware
token to digitally sign ... w/o the associated human's knowledge
2) compromised software that displays one thing but provides the
hardware token with something completely different for actual digital
signature (display a transaction for $5 but the actual digital
signature is on a transaction of $500).
the basic EU FINREAD terminal standard provided some protection to the
user against compromised software on their personal PC. However, there
is nothing in the basic standard that provides proof to a relying
party that such a terminal was used for the operation.
for the x9.59 financial standard, the x9a10 working group had been
given the requirement to preserve the integrity of the financial
infrastructure for all retail payments
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959
the x9.59 financial standard allows for a (hardware token) digital
signature (for something you have authentication) as well as a
certified terminal digital signature.
the digital signature by the certified terminal, isn't so much for
authentication ... but as evidence (to a relying party) that certain
processes had been followed that provides some basis for inferring human
intent as basis for human signature (i.e. read, understood, agrees,
approves, and/or authorizes).
the "digital signature" by the hardware token is simple something
you have authentication ... but does not imply "human
signature". it is the digital signature by the certified terminal that
inplies a process that be used to imfer human signature.
a couple recent postings dealing with digital signatures for
being able to attest to something
http://www.garlic.com/~lynn/aadsm25.htm#35 signing all outbound email
http://www.garlic.com/~lynn/aadsm25.htm#44 TPM & disk crypto
and various past posts mentioning dual-use attack on digital
signature operations:
http://www.garlic.com/~lynn/aadsm17.htm#57 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#1 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#2 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#3 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#56 two-factor authentication problems
http://www.garlic.com/~lynn/aadsm19.htm#41 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm19.htm#43 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm21.htm#5 Is there any future for smartcards?
http://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the security challenges
http://www.garlic.com/~lynn/aadsm23.htm#13 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#21 New Method for Authenticated Public Key Exchange without Digital Certificates
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Turbo C 1.5 (1987)
Newsgroups: alt.folklore.computers
Date: Wed, 18 Oct 2006 12:00:53 -0600
scott writes:
I am looking for a copy of Turbo C 1.5 from 1987 for some historical
research I'm doing into computing from that time period.
Turbo C 1.0 and 1.5 were different from 2.0 -- by the time 2.0 came
out, Borland was switching to its "classic" blue window that was seen
from that point onward. Version 1 had the black background in Turbo
Basic 1.1 and Turbo Prolog 2, which were contemporaries. By the time
Turbo C 2 came out, the black background products were gone - the main
Turbo C and Turbo Pascal got the "classic" look in their next
releases. For historical accuracy in screen grabs and something I'm
writing, I would like to be able to do screen captures of 1.5. I have
been unable to find it at the Borland museum, Vetusware.com, eMule,
etc although almost all other versions are available; I haven't even
seen it for sale. (Note: The museum has Turbo *C++* 1.0, which is
OFTEN mislabeled as "Turbo C 1.0". The Turbo C labelled as 1.0 at
Vetusware.com is actually 2.0.) The only hope I have is if someone has
a copy...
I am also not sure if 1.5 implements the then-draft ANSI standard. I
am eager to look into the header files and see if it does. 2.0, which
was released in 1988, seems to adhere to what was still (I think) a
draft standard at the time it came out. The 1.5 release may still have
been a K&R compiler. (The 1.0 release is said to be extremely buggy -
1.5 was a release that apparently was more a bug fix than anything
else.)
i've been looking for a way to read the 100 or so 5.25in. diskettes
that I still have. I've got four (personal) diskettes that are say
they are backup versions of various versions of turbo pascal. I've
also got turbo pascal installation diskettes
v2 ... copyright 1983
v3.01a ... copyright 1983
no version number, but says copyright 1987
v5.5 ... copyright 1987, 1989
i've got three different sets of turbo c installation diskettes (but
they don't carry version numbers).
four diskettes copyright 1986 (black label with pink? corner symbol)
ide, command line/utilities, header files/libraries/examples,
libraries/examples
five diskettes copyright 1986 (black label with blue corner symbol)
ide, command line/utilities, header files/libraries, libraries,
examples
six diskettes copyright 1987, 1988 (yellow label)
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Turbo C 1.5 (1987)
Newsgroups: alt.folklore.computers
Date: Wed, 18 Oct 2006 13:45:04 -0600
Al Kossow <aek@spies.com> writes:
I would suggest using Imagedisk
http://www.classiccmp.org/dunfield/img/
If you need a drive, I should be able to loan one to you, or if they are of
historical interest, I could read the floppies for you at the Museum.
re:
http://www.garlic.com/~lynn/2006s.html#35 Turbo C 1.5 (1987)
the installation diskettes i could donate ... but would still like to
have access to a drive ... to try and read the rest of the other
diskettes ... i've got several that say dos 1.86 (released internally
with lots of bells and whistles) ... which look to be dual-sided 40trk
diskettes ... but i believe formatted with 80trks/side and possibly 10
sectors per track (vanilla original density was 9sectors per track).
i believe the AT high-density 5.25in. diskette readers could be used
to read normal density 40trk diskettes (as long as you didn't try
writting) ... and with the right software also read normal density
dual-sided 40trk diskettes formated w/80trks. I once had an early
(employee purchase plan) pc with a pair of standard diskettes
... which I eventually added a pair of half-height teac external
drives ... that were capable of normal density 80trk operation.
normal density, single-side, 40trk 8sectors/track were 160kbytes.
normal density single-side 40trk, 9sectors/track was 180kbyte,
dual-sided 40trk, 9sectors/track was 360kbyte. the normal density,
dual-sided 80trk, 10sectors/track were 800kbyte ... while the (PC/AT)
high-density, dual-sided 80trk were 1.2mbyte.
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Turbo C 1.5 (1987)
Newsgroups: alt.folklore.computers
Date: Wed, 18 Oct 2006 15:36:24 -0600
scott writes:
Also, for people doing research along this line, the Turbo C++ 1.0 or
1.01 image at the Borland Museum has circulated on the Internet through
web pages and file sharing and is often mislabeled as Turbo C 1.0.
Maybe people don't know the difference, but you will frequently see the
C++ compiler mislabeled as Turbo C 1.0. The two are very different
compilers released about 4-5 years apart.
i also have a couple different verions of turbo C++ installation
diskettes (these are 3.5in ) ... which are different from the turbo C
(5.25in) installation diskettes.
re:
http://www.garlic.com/~lynn/2006s.html#35 Turbo C 1.5 (1987)
http://www.garlic.com/~lynn/2006s.html#36 Turbo C 1.5 (1987)
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Design life of S/360 components?
Newsgroups: alt.folklore.computers
Date: Wed, 18 Oct 2006 15:45:24 -0600
"Ancient_Hacker" <grg2@comcast.net> writes:
Not that critical a consideration in those days. Labor was cheap,
computers were expensive. Plus a IBM engineer had to show up once a
week to oil up the card reader and clean the tape drives.
my first student programming job was to do a 360 assembler port of
1401 MPIO program. The university had 709 with a 1401 handling unit
record .... i.e. card-to-tape and tape-to-printer/punch.
as part of transition, the got a 360/30 replacement for the 1401. they
could run the 360/30 in 1401 hardware emulation mode (performing unit
record front end for the 709). my job was to implement the 709 unit
record front end functions in 360 assembler.
i got to design and implement my own monitor, interrupt handler,
device drivers, storage allocation, etc. normal university operation
was to shutdown the datacenter 8am on saturday and not resume until
8am monday. this met that i normally could have the whole datacenter
to myself from 8am saturday until business resumed on 8am monday (48hr
shift and then quick break/shower before going to monday classes).
I fairly quickly learned that before starting anything else, to first
clean the tape heads (something the operators would normally do at the
start of each shift) ... and also take the 2540 reader/punch apart and
clean it.
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why these original FORTRAN quirks?
Newsgroups: alt.folklore.computers
Date: Wed, 18 Oct 2006 16:53:50 -0600
Peter Flass <Peter_Flass@Yahoo.com> writes:
Now I'm confused. First I agreed with you, on second thought I
realized HASP probably translated the control characters, on third
thought, I remembered we used ASA control characters with DOS and no
spooler, so the 1403 and follow-ons must have processed the ASA
control characters in hardware.
from gcard ios3270 converted to html
http://www.garlic.com/~lynn/gcard.html
http://www.garlic.com/~lynn/gcard.html#9 ANSI control characters
Code Action before printing Code Stacker
blank Space 1 line V 1
0 Space 2 line W 2
- Space 3 line X 3
+ Suppress space Y 4
1 Skip to channel 1 (line 1 on new page) Z 5
2 Skip to channel 2
3 Skip to channel 3
4 Skip to channel 4
5 Skip to channel 5
6 Skip to channel 6
7 Skip to channel 7
8 Skip to channel 8
9 Skip to channel 9
A Skip to channel 10
B Skip to channel 11
C Skip to channel 12
... snip ...
i.e. control characters were the first byte of the data.
if the first byte of the data was indicated as control character, then
the printer driver would generate a ccw that did the appropriate
control function ... followed by a ccw that wrote the rest of the
data to the printer.
and printer (ccw) command codes
http://www.garlic.com/~lynn/gcard.html#24 Printer Control Characters
Action After Write Immediate
Space 0 Lines 01 01 (sometimes called write without spacing)
Space 1 Line 09 0B
Space 2 Lines 11 13
Space 3 Lines 19 1B
Skip to Channel 0 - 83 (3211 and 3203-4 only)
Skip to Channel 1 89 8B
Skip to Channel 2 91 93
Skip to Channel 3 99 9B
Skip to Channel 4 A1 A3
Skip to Channel 5 A9 AB
Skip to Channel 6 B1 B3
Skip to Channel 7 B9 BB
Skip to Channel 8 C1 C3
Skip to Channel 9 C9 CB
Skip to Channel 10 D1 D3
Skip to Channel 11 D9 DB
Skip to Channel 12 E1 E3
... snip ...
i.e. the control characters in the first byte were then directly
as the CCW command code.
the printer CCW command code performed the indicated control operation
after writing the associated line ... while the ANSI control
characters indicated the operation to be performed before writing the
associated line.
the brain dead printer driver would convert ANSI control into a pair
of CCWs, first was a CCW that performed just the immediate control
operation chained to a CCW that did write immediate (w/o any motion).
fancier printer driver ... would take the ANSI control operation
indicated by the following line ... and use it to modify the
CCW for the previous line.
say ANSI had three lines with a blank in the first byte followed
by a a line with "1" in the first byte (skip to start of page).
the brain dead operation would be CCW channel program:
0B space line
01 write data, no space
0B space line
01 write data, no space
0B space line
01 write data, no space
8B skip to channel 1 (start of page)
01 write data, no space
so a little fancier would be
0B space line
09 write data, space line
09 write data, space line
89 write data, skip to channel 1 (start of page)
01 write data, no space
........
so standard os/360 used DCB/DD RECFM parameter to indicate whether
the first byte was ANSI printer control or machine printer control.
various combinations of RECFM= paramemter:
F FA FB FBA
FBM FBS FBSA FBSM
FM FS FSA FSM
V VA VB VBA
VBM VM U UA
UM
where
F - Fixed length records.
V - Variable length records.
U - Undefined length records.
B - Blocked records.
S - Standard blocks.
A - ANSI printer control characters are in the first byte of each record.
M - Machine printer control characters are in the first byte of each record.
... snip ...
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Ranking of non-IBM mainframe builders?
Newsgroups: alt.folklore.computers
Date: Thu, 19 Oct 2006 10:26:08 -0600
hancock4 writes:
*Back then machines were so damn expensive we stretched them to the
limit. We had a dual 158 with 6 Meg and we probably could've used a
168 with 8 or 10 meg instead. Programmers were encouraged to work odd
hours to compile and test when the machine was less busy. Capacity
control was a big issue back then. We upgraded (3031?) and had more
power.
158 had integrated channels ... the microcode engine was shared between
the microcode implementing 370 and the microcode implementing channel
(i/o).
for the 303x series ... they packaged a 158 microcode engine w/o the
370 microcode (just the integrated channels) as a "channel
director". then all the 303x machines got external channel director
boxes ...
the 3031 was a 158 microcode engine with just the 370 microcode and a
separate 158 microcode engine as a "channel director" (running the
integrated channel microcode). the 3031 was ex