List of Archived Posts
2008 Newsgroup Postings (01/01 - 01/15)
- It keeps getting uglier
- LINC-8 Front Panel Questions
- folklore indeed
- No Glory for the PDP-15
- folklore indeed
- folklore indeed
- It keeps getting uglier
- folklore indeed
- folklore indeed
- folklore indeed
- For the History buff's an IBM 5150 pc
- Information security breaches quadrupled in 2007
- No Glory for the PDP-15
- LINC-8 Front Panel Questions
- hacked TOPS-10 monitors
- hacked TOPS-10 monitors
- No Glory for the PDP-15
- Usefulness of bidirectional read/write?
- Remembering the Cray-1
- Tap and faucet and spellcheckers [was: Re: What do YOU call
- Tap and faucet and spellcheckers [was: Re: What do YOU call
- No Glory for the PDP-15
- Tap and faucet and spellcheckers
- z/OS and VM Control Blocks
- Need Help filtering out sporge in comp.arch
- Tap and faucet and spellcheckers
- Tap and faucet and spellcheckers
- Tap and faucet and spellcheckers
- As Expected, Ford Falls From 2nd Place in U.S. Sales
- Need Help filtering out sporge in comp.arch
- hacked TOPS-10 monitors
- 1975 movie "Three Days of the Condor" tech stuff
- 1975 movie "Three Days of the Condor" tech stuff
- JCL parms
- 1970s credit cards, was: 1975 movie "Three Days of the Condor" tech stuff
- U.S. Identity Theft at Record Level in 2007
- 1970s credit cards, was: 1975 movie "Three Days of the Condor" tech stuff
- 1975 movie "Three Days of the Condor" tech stuff
- JCL parms
- competitiveness
- No Gory for the *NIX
- IT managers stymied by limits of x86 virtualization
- Inaccurate CPU% reported by RMF and TMON
- dig. TV
- Computer Science Education: Where Are the Software Engineers of Tomorrow?
- No Glory for the PDP-15
- Computer Science Education: Where Are the Software Engineers of Tomorrow?
- dig. TV
- As Expected, Ford Falls From 2nd Place in U.S. Sales
- IBM LCS
- IT managers stymied by limits of x86 virtualization
- IBM LCS
- Education ranking
- Really stupid question about z/OS HTTP server
- Really stupid question about z/OS HTTP server
- Education ranking
- Computer Science Education: Where Are the Software Engineers of Tomorrow?
- Computer Science Education: Where Are the Software Engineers of Tomorrow?
- IBM LCS
- old internal network references
- Education ranking
- 1975 movie "Three Days of the Condor" tech stuff
- competitiveness
- LINC-8 Front Panel Questions
- Radix Partition Trees
- As Expected, Ford Falls From 2nd Place in U.S. Sales
- As Expected, Ford Falls From 2nd Place in U.S. Sales
- File Transfer conundrum
- Computer Science Education: Where Are the Software Engineers of Tomorrow?
- Rotary phones
- As Expected, Ford Falls From 2nd Place in U.S. Sales
- As Expected, Ford Falls From 2nd Place in U.S. Sales
- Radix Partition Trees
- Computer Science Education: Where Are the Software Engineers of Tomorrow?
- Virtualization Wave
- Rotary phones
- Rotary phones
- Radix Partition Trees
- As Expected, Ford Falls From 2nd Place in U.S. Sales
- Rotary phones
- Toyota Sales for 2007 May Surpass GM
- Education ranking
- Rotary phones
- Education ranking
- Toyota Sales for 2007 May Surpass GM
- Toyota Sales for 2007 May Surpass GM
- Toyota Sales for 2007 May Surpass GM
- Computer Science Education: Where Are the Software Engineers of Tomorrow?
- folklore indeed
- folklore indeed
- Computer Science Education: Where Are the Software Engineers of Tomorrow?
It keeps getting uglier
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: It keeps getting uglier
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 01 Jan 2008 08:07:42
Steve_Thompson@STERCOMM.COM (Thompson, Steve) writes:
WANG with their WANG/VS systems came up with an idea that would have met
your problem. The workstations had a button that caused the CEC to
download microcode for DP/WP (Data Processing / Word Processing). So
your workstation could switch between types of work. [ASCII based S/360
type architecture on steroids.]
IBM attempted to make a product to market against WANG. They couldn't
figure out how to do it economically. Problem was the distance from the
tree to the eyeballs of the powers that were was about 2 inches. The
problem was solved by having a PC that could do word processing while
having an emulator (3270) for the 3270 type tasks, and then the PC would
handle the word processing type tasks.
for some topic drift ... past posts about PC getting early market
traction because it sold for about the same price as 3270 and
in single desktop footprint could get 3270 terminal emulation
and some local (personal) computing
http://www.garlic.com/~lynn/subnetwork.html#emulation
OPD's displaywriter was in WANG wordprocessing market segment.
ROMP was early 801 risc chip originally designed to be used for
displaywriter follow-on product. when that was killed, the group looked
around for something else to use the machine for and settled on the unix
workstation market. they got the company that had done the pc/ix port to
do one for the displaywriter "follow-on" and renamed the product the
PC/RT (and the software AIX).
http://www.garlic.com/~lynn/subtopic.html#801
The PC/RT followon was the RS6000 with RIOS chipset. RS6000 was
relogo'ed as hardware platfrom by some number of other companies
... including WANG as it got out of the hardware business. As part of
that change-over, some number of the people from RS6000 group went to
WANG.
old time article from nov80 mentioning wang, word-processing market
http://www.time.com/time/magazine/article/0,9171,950498,00.html?iid=chix-sphere
page mentioning some of the old/70s wordprocessing market
http://www.computermuseum.li/Testpage/DedicatedWPMicros.htm
article on demise of dedicated wordprocessor boxes; having given away to
multi-application PCs
http://www.cbronline.com/article_cg_print.asp?guid=265D4108-6F66-49EC-80B1-E51D2AA8876E
note that there was a project in the early 80s to replace the wide
variety of internal microprocessors with 801/risc processors (including
the ones used for displaywriters). this included all the processors in
the low and mid-range 370s ... at the time, the 4341-followon (4381) was
going to use a 801/risc processor; the s/38-followon (as/400) was going
to use a 801/risc processor ... and lots of others were also. A special
flavor of 801/risc, Iliad had additional features for supporting
emulation of other architectures ... some old 801-related email,
including mention of work on Iliad chips
http://www.garlic.com/~lynn/lhwemail.html#801
for other topic drift, old email mentioning 43xx ... "e-architecture"
machines
http://www.garlic.com/~lynn/lhwemail.html#43xx
i.e. while the high-end 370 came up with 370-xa (code named "811" for
nov78 document publication date), the low/mid range came up with
"e-architecture" (where dos/vs to vse came from).
for some archeological trivia, i contributed to the document killing
801/risc idea for the 4341-followon.
LINC-8 Front Panel Questions
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: LINC-8 Front Panel Questions
Newsgroups: alt.folklore.computers
Date: Tue, 01 Jan 2008 11:58:07
jmfbahciv writes:
He was wrong. There are still thousands, millions? of tape that
contains data. Weren't you the one who talked about data NASA can't
retrieve because it's on tape? Until all data on tape is transferred
off those tapes, tapes are not dead.
hot off the press ...
IBM: Tape Backup is Here to Stay
http://www.enterpriseitplanet.com/storage/features/article.php/3719041
from:
"In order to maintain continuous business operations, address
regulatory requirements and archive business records, users need an
infrastructure that allows them to manage their data from online
application storage to offline, permanent archive media," says IBM's
Bruce Master, senior program manager, Worldwide Tape Storage Systems
Marketing. "Tape backup is a key part of this life cycle, allowing
users to safely store long term archives for record keeping and disaster
recovery while managing total costs of ownership (TCO)."
... snip ...
i mentioned before that when we were out marketing our 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 were also asked to write a section in the corporations continuous
availability strategy document ... however both rochester and pok
complained (as they couldn't meet at the time), and the section was
pulled.
also from the above:
"IBM TS1120 tape drive and EKM technology is used in high-end
enterprise accounts by Fortune 100 companies in a variety of industries
including banking, finance and securities," says Master. "IBM's LTO
tape offerings have achieved nearly 900,000 drive shipments and over 10
million cartridge shipments."
... snip ...
folklore indeed
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: folklore indeed
Newsgroups: alt.folklore.computers
Date: Tue, 01 Jan 2008 12:33:26
Charlton Wilbur <cwilbur@chromatico.net> writes:
Exactly! The mompop can gross $15K, and then spend $5K-$15K on the
auditing for their in-house credit card processing; or they can gross
$15K, and then spend a couple hundred dollars for their share of the
auditing on the service that processes credit cards for them and 100
other mompops.
but the analysis is that the attractiveness to the crooks can scale
fairly linear with number of accounts ... and given security
proportional to risk ... $15k-$30k annually (the necessary fraud
countermeasures along with the audit of those countermeasures) is
possibly proportional to the associated risk for the small mompops.
however, with the risk scaling linearly ... aggregation means that the
countermeasures have to also increase enormously ... i.e. the refrain
that the attackers can outspend the defenders by possibly 100:1.
a little military/boyd topic drift ... i think there is some guideline
is that attackers need something like 3:1 for taking on a fixed defense
... being able to marshall 100:1, massively overwhelms fixed defense.
recent security thread mentioning boyd (& OODA-loop)
http://www.garlic.com/~lynn/aadsm28.htm#3 Why Security Modelling doesn't work -- the OODA-loop of today's battle
one could also claim that massive financial incentive also motivates
them to more quickly cycle their OODA-loop. misc. past posts mentioning
boyd
http://www.garlic.com/~lynn/subboyd.html#boyd
recent posts mentioning security proportional to risk and/or attackers
can afford to enormously outspend the defenders.
http://www.garlic.com/~lynn/aadsm26.htm#58 Our security sucks. Why can't we change? What's wrong with us?
http://www.garlic.com/~lynn/aadsm27.htm#3 Solution to phishing -- an idea who's time has come?
http://www.garlic.com/~lynn/aadsm28.htm#3 Why Security Modelling doesn't work -- the OODA-loop of today's battle
http://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007f.html#75 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007g.html#20 T.J. Maxx data theft worse than first reported
http://www.garlic.com/~lynn/2007h.html#56 T.J. Maxx data theft worse than first reported
http://www.garlic.com/~lynn/2007i.html#64 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007j.html#15 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#39 My Dream PC -- Chip-Based
http://www.garlic.com/~lynn/2007l.html#48 My Dream PC -- Chip-Based
http://www.garlic.com/~lynn/2007v.html#86 folklore indeed
http://www.garlic.com/~lynn/2007v.html#87 Data Breaches Soar In 2007
http://www.garlic.com/~lynn/2007v.html#90 folklore indeed
http://www.garlic.com/~lynn/2007v.html#91 Tap and faucet and spellcheckers
http://www.garlic.com/~lynn/2007v.html#93 folklore indeed
http://www.garlic.com/~lynn/2007v.html#94 folklore indeed
http://www.garlic.com/~lynn/2007v.html#97 folklore indeed
No Glory for the PDP-15
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: No Glory for the PDP-15
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Tue, 01 Jan 2008 14:12:05
"Carl Appellof" <doctorcja@yahoo.com> writes:
I think it would have been tough, even in microcode, to emulate a 36-bit
machine with a 32-bit architecture.
there were number of microengines used to emulate 360, 1401, 1410, 1610,
7090, etc
recent reference here to 360/30
http://www.garlic.com/~lynn/2007v.html#99 It keeps getting uglier
and some numbere of 360 FE manuals
http://bitsavers.org/pdf/ibm/360/fe/
which makes some reference to the native hardware of the machines
... and at least for 360/30, talks about 1401 & 1610 emulation mode.
360/65 had front panel selector for 709x emulation
a misc references to (36-bit) 709x:
IBM 7090 CompWisdom
http://www.compwisdom.com/topics/IBM-7090
IBM Archives: 7090 Data Processing System
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP7090.html
IBM Archives: 7090 Data Processing System (continued)
http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP7090B.html
IBM 7090/94 Architecture Home Page
http://dgatx.com/computing/people/Jack-Harper/pubs/2004/IBM-7090/archive.html
folklore indeed
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: folklore indeed
Newsgroups: alt.folklore.computers
Date: Tue, 01 Jan 2008 14:42:36
Charlton Wilbur <cwilbur@chromatico.net> writes:
Leaping from "attractiveness scales linearly" to "risk scales
linearly" is not warranted, I think. If I were a crook, and I had the
choice between cracking difficult security at a TJX and cracking easy
security at a mompop, I'd go for the mompop every time. Crooks aren't
stupid; a 10% chance at $15K is as good as a 1% chance at $150K or a
0.01% chance at $1.5 million.
re:
http://www.garlic.com/~lynn/2008.html#2 folklore indeed
that is the outsider attack scenario ... the numbers indicate that as
much as 70percent of such data breaches involve insiders. I've mentioned
before that one of the results of focusing on the outsider issues will
tend to obfuscate looking at major source, the insiders.
also, the large breaches are much more likely to make national press
... using news search engines ... there are quite a bit of purely
"local" incidents hundreds.
there is also the scenario, that the financial institutions have fraud
pattern analysis that are somewhat tuned to the "large" breaches
... looking at possibly hundred or thousands of account fraud reports
and attempting to find some common transactions for the accounts
(potentially indicating a common breach).
the "percentage chance" methodology tends to ignore sophistication level
of crooks and/or amount of money that crooks might be willing to invest
(i.e. crooks can afford to outspend defenders by as much as 100:1).
smaller operation will tend to have less sophisticated countermeasures
and therefor more attactive to less sophisticated criminal activity.
the sophistication of the countermeasures will tend to increase with the
size of the operation ... which may mean some self-selection with regard
to the sophistication of criminals doing the attacks.
the enormous multitude and variety of attacks is related to the posts in
the naked transaction metaphor threads
http://www.garlic.com/~lynn/subintegrity.html#payments
which can be considered the root of the scenario where "crooks can
afford to enormously outspend attackers" and the huge imbalance in the
security proportional to risk ... (and possibly except for the x9.59
financial standard work) ... everything else is mostly patchwork and
simple point solution security measures.
past references/posts mentioning insiders:
http://www.garlic.com/~lynn/aadsm12.htm#44 Identity Theft More Often an Inside Job
http://www.garlic.com/~lynn/aadsm12.htm#58 Time to ID Identity-Theft Solutions
http://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
http://www.garlic.com/~lynn/aadsm14.htm#12 Tackling security threats from within
http://www.garlic.com/~lynn/aadsm14.htm#28 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/aadsm17.htm#38 Study: ID theft usually an inside job
http://www.garlic.com/~lynn/aadsm17.htm#39 The future of security
http://www.garlic.com/~lynn/aadsm17.htm#47 authentication and authorization ... addenda
http://www.garlic.com/~lynn/aadsm17.htm#50 authentication and authorization (was: Question on the state of the security industry)
http://www.garlic.com/~lynn/aadsm17.htm#60 Using crypto against Phishing, Spoofing and Spamming
http://www.garlic.com/~lynn/aadsm18.htm#6 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#29 EMV cards as identity cards
http://www.garlic.com/~lynn/aadsm18.htm#49 one more time now, Leading Cause of Data Security breaches Are Due to Insiders, Not Outsiders
http://www.garlic.com/~lynn/aadsm19.htm#17 What happened with the session fixation bug?
http://www.garlic.com/~lynn/aadsm19.htm#19 "SSL stops credit card sniffing" is a correlation/causality myth
http://www.garlic.com/~lynn/aadsm22.htm#2 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#3 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm22.htm#27 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#33 Meccano Trojans coming to a desktop near you
http://www.garlic.com/~lynn/aadsm22.htm#36 Unforgeable Blinded Credentials
http://www.garlic.com/~lynn/aadsm23.htm#0 Separation of Roles - an example
http://www.garlic.com/~lynn/aadsm23.htm#9 PGP "master keys"
http://www.garlic.com/~lynn/aadsm23.htm#10 PGP "master keys"
http://www.garlic.com/~lynn/aadsm23.htm#44 ThreatWatch - markets in loss, Visa's take, 419 "chairmen"
http://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
http://www.garlic.com/~lynn/aadsm24.htm#7 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#10 Naked Payments IV - let's all go naked
http://www.garlic.com/~lynn/aadsm24.htm#36 Interesting bit of a quote
http://www.garlic.com/~lynn/aadsm24.htm#48 more on FBI plans new Net-tapping push
http://www.garlic.com/~lynn/aadsm25.htm#13 Sarbanes-Oxley is what you get when you don't do FC
http://www.garlic.com/~lynn/aadsm25.htm#41 Why security training is really important (and it ain't anything to do with security!)
http://www.garlic.com/~lynn/aadsm26.htm#7 Citibank e-mail looks phishy
http://www.garlic.com/~lynn/aadsm27.htm#31 The bank fraud blame game
http://www.garlic.com/~lynn/aadsm27.htm#52 more on firing your MBA-less CSO
http://www.garlic.com/~lynn/aadsm27.htm#53 Doom and Gloom spreads, security revisionism suggests "H6.5: Be an adept!"
http://www.garlic.com/~lynn/aadsm27.htm#60 Retailers try to push data responsibilities back to banks
http://www.garlic.com/~lynn/2001c.html#45 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001g.html#38 distributed authentication
http://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean Anything?
http://www.garlic.com/~lynn/2002.html#12 A terminology question
http://www.garlic.com/~lynn/2002d.html#14 Mainframers: Take back the light (spotlight, that is)
http://www.garlic.com/~lynn/2002f.html#35 Security and e-commerce
http://www.garlic.com/~lynn/2002j.html#14 Symmetric-Key Credit Card Protocol on Web Site
http://www.garlic.com/~lynn/2004i.html#5 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004i.html#16 New Method for Authenticated Public Key Exchange without Digital Ceritificates
http://www.garlic.com/~lynn/2004j.html#15 US fiscal policy (Was: Bob Bemer, Computer Pioneer,Father of ASCII,Invento
http://www.garlic.com/~lynn/2004j.html#37 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2005g.html#33 Good passwords and security priorities
http://www.garlic.com/~lynn/2005g.html#37 MVS secure configuration standard
http://www.garlic.com/~lynn/2005i.html#1 Brit banks introduce delays on interbank xfers due to phishing boom
http://www.garlic.com/~lynn/2005i.html#11 Revoking the Root
http://www.garlic.com/~lynn/2005j.html#52 Banks
http://www.garlic.com/~lynn/2005k.html#1 More on garbage
http://www.garlic.com/~lynn/2005k.html#55 Encryption Everywhere? (Was: Re: Ho boy! Another big one!)
http://www.garlic.com/~lynn/2005l.html#29 Importing CA certificate to smartcard
http://www.garlic.com/~lynn/2005l.html#35 More Phishing scams, still no SSL being used
http://www.garlic.com/~lynn/2005o.html#2 X509 digital certificate for offline solution
http://www.garlic.com/~lynn/2005v.html#2 ABN Tape - Found
http://www.garlic.com/~lynn/2006c.html#35 X.509 and ssh
http://www.garlic.com/~lynn/2006d.html#26 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006d.html#28 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#26 Debit Cards HACKED now
http://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
http://www.garlic.com/~lynn/2006h.html#15 Security
http://www.garlic.com/~lynn/2006h.html#26 Security
http://www.garlic.com/~lynn/2006k.html#4 Passwords for bank sites - change or not?
http://www.garlic.com/~lynn/2006k.html#16 Value of an old IBM PS/2 CL57 SX Laptop
http://www.garlic.com/~lynn/2006k.html#23 Value of an old IBM PS/2 CL57 SX Laptop
http://www.garlic.com/~lynn/2006k.html#33 Password Complexity
http://www.garlic.com/~lynn/2006p.html#9 New airline security measures in Europe
http://www.garlic.com/~lynn/2006u.html#40 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006u.html#43 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#2 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#42 On sci.crypt: New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006v.html#49 Patent buster for a method that increases password security
http://www.garlic.com/~lynn/2006x.html#14 IBM ATM machines
http://www.garlic.com/~lynn/2007.html#42 The logic of privacy
http://www.garlic.com/~lynn/2007b.html#13 special characters in passwords
http://www.garlic.com/~lynn/2007b.html#20 How many 36-bit Unix ports in the old days?
http://www.garlic.com/~lynn/2007b.html#33 security engineering versus information security
http://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#10 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#11 Decoding the encryption puzzle
http://www.garlic.com/~lynn/2007c.html#32 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#35 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007c.html#43 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007f.html#75 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007i.html#28 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#65 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007l.html#35 My Dream PC -- Chip-Based
http://www.garlic.com/~lynn/2007n.html#85 PCI Compliance - Encryption of all non-console administrative access
http://www.garlic.com/~lynn/2007n.html#94 PCI Compliance - Encryption of all non-console administrative access
http://www.garlic.com/~lynn/2007o.html#0 The Unexpected Fact about the First Computer Programmer
http://www.garlic.com/~lynn/2007q.html#11 what does xp do when system is copying
http://www.garlic.com/~lynn/2007q.html#72 Value of SSL client certificates?
http://www.garlic.com/~lynn/2007v.html#74 folklore indeed
http://www.garlic.com/~lynn/2007v.html#94 folklore indeed
folklore indeed
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: folklore indeed
Newsgroups: alt.folklore.computers
Date: Tue, 01 Jan 2008 15:08:39
Charlton Wilbur <cwilbur@chromatico.net> writes:
And at the root of it all is, there's no need to store the credit card
number, the valuable part, in the first place. You submit it to the
credit card processor, and they reply with an authorization code and a
reference number. That authorization code and reference number is
sufficient to get the money from the credit card processor, and the
credit card number is no longer needed.
re:
http://www.garlic.com/~lynn/2008.html#2 folklore indeed
as noted repeatedly before ... there are some number of business
processes, like disputes & chargebacks ... that mandate the
retention of the transaction account number & date/time (which
survive long after the merchant having received their money).
also as referenced in previous posts ... the national retailers
federation have raised the issue of changing the retention mandates.
http://www.garlic.com/~lynn/aadsm27.htm#60 Retailers try to push data responsibilities back to banks
there is some conjecture that the financial institutions may resist
becoming responsible for the transaction activity respository with
lots of distributed access from their retailers and merchants ...
since there would be a huge number of breach opportunities
(represented by all those authorized accesses) and the financial
institution then becomes liable (rather than the merchant for the
breach).
also this reference to large national retailer
http://www.garlic.com/~lynn/2007v.html#95 folklore indeed
had calculated that the current transaction information retention
mandates were costing more than automatically paying all existing
disputes and chargebacks ... and was seriously considering dumping
the data, ignoring the retention mandates and just automatically
paying off dispuates and chargebacks. Or, at least until somebody
raised the issue what might happened if that became public knowledge.
however, since with the underlying naked transaction metaphor
http://www.garlic.com/~lynn/subintegrity.html#payment
there is still an enormous end-to-end vulnerability ... having
aggregated repositories with a large number of "insiders" with access
from widely distributed locations ... can create a new set of exploit
avenues.
in the security proportional to risk scenario, the breach
itself isn't the risk, the risk is that the crooks use the
information for fraudulent transactions.
in the x9.59 financial standard scenario
http://www.garlic.com/~lynn/x959.html#x959
the risk isn't reduced by securing all possible breaches and/or all
possible other points where crooks might be able to obtain the
information ... for complete end-to-end security ... as per the
requirement placed on the x9a10 financial standard working group to
preseve the integrity of the financial infrastructure for *ALL*
retail payments ... in x9.59 financial standard protocol, the risk
is reduced by eliminating the crooks being able to use the information
for fraudulent transactions.
misc. posts mentioning disputes, chargebacks, and/or references
to NRF wanting the financial institutions to change the information
retention mandates
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aepay3.htm#disputes Half of Visa's disputes, fraud result from I-commerce (more)
http://www.garlic.com/~lynn/aadsm6.htm#nonreput Sender and receiver non-repudiation
http://www.garlic.com/~lynn/aadsm6.htm#terror7 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#terror12 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#terror13 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm6.htm#terror14 [FYI] Did Encryption Empower These Terrorists? (addenda to chargebacks)
http://www.garlic.com/~lynn/aepay7.htm#nonrep0 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep3 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep5 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aepay7.htm#nonrep6 non-repudiation, was Re: crypto flaw in secure mail standards
http://www.garlic.com/~lynn/aadsm7.htm#rubberhose Rubber hose attack
http://www.garlic.com/~lynn/aepay10.htm#41 ATM Scams - Whose Liability Is It, Anyway?
http://www.garlic.com/~lynn/aadsm10.htm#tamper Limitations of limitations on RE/tampering (was: Re: biometrics)
http://www.garlic.com/~lynn/aadsm12.htm#63 Intertrust, Can Victor Shear Bring Down Microsoft?
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm19.htm#44 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm2.htm#useire U.S. & Ireland use digital signature
http://www.garlic.com/~lynn/aadsm20.htm#22 ID "theft" -- so what?
http://www.garlic.com/~lynn/aadsm21.htm#36 browser vendors and CAs agreeing on high-assurance certificates
http://www.garlic.com/~lynn/aadsm23.htm#14 Shifting the Burden - legal tactics from the contracts world
http://www.garlic.com/~lynn/aadsm23.htm#33 Chip-and-Pin terminals were replaced by "repairworkers"?
http://www.garlic.com/~lynn/aadsm26.htm#10 Who has a Core Competency in Security?
http://www.garlic.com/~lynn/aadsm26.htm#44 Governance of anonymous financial services
http://www.garlic.com/~lynn/aadsm26.htm#48 Governance of anonymous financial services
http://www.garlic.com/~lynn/aadsm26.htm#63 Public key encrypt-then-sign or sign-then-encrypt?
http://www.garlic.com/~lynn/2000.html#57 RealNames hacked. Firewall issues.
http://www.garlic.com/~lynn/2001j.html#2 E-commerce security????
http://www.garlic.com/~lynn/2001l.html#52 Security standards for banks and other institution
http://www.garlic.com/~lynn/2002d.html#41 Why?
http://www.garlic.com/~lynn/2002f.html#10 Least folklorish period in computing (was Re: IBM Mainframe at home)
http://www.garlic.com/~lynn/2002m.html#36 (OT) acceptance of technology, was: Convenient and secure
http://www.garlic.com/~lynn/2003l.html#65 Strength of RSA with known plain-text
http://www.garlic.com/~lynn/2004i.html#17 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005e.html#41 xml-security vs. native security
http://www.garlic.com/~lynn/2007h.html#28 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007i.html#23 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007i.html#64 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007j.html#67 open source voting
http://www.garlic.com/~lynn/2007r.html#32 Is the media letting banks off the hook on payment card security
http://www.garlic.com/~lynn/2007r.html#66 The new urgency to fix online privacy
http://www.garlic.com/~lynn/2007v.html#62 folklore indeed
http://www.garlic.com/~lynn/2007v.html#85 folklore indeed
http://www.garlic.com/~lynn/2007v.html#94 folklore indeed
It keeps getting uglier
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: It keeps getting uglier
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Tue, 01 Jan 2008 15:14:17
edgould1948@COMCAST.NET (Ed Gould) writes:
Rick:
FYI according to lynn@GARLIC.COM the model 85 was the 1st 360 to have
a HSB.
re:
http:/www.garlic.com/~lynn/2007v.html#98 It keeps getting uglier
not just me:
http://www-03.ibm.com/ibm/history/history/year_1968.html
from above:
Additions to System/360 family are announced, including the Model
85. The high-speed cache, or buffer memory, found in the System/360
Model 85, is the first in the industry. The cache memory makes highly
prioritized information available at 12 times the speed of regular,
main-core memory.
... snip ...
not only first 360 ... but "first in the industry".
folklore indeed
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: folklore indeed
Newsgroups: alt.folklore.computers
Date: Tue, 01 Jan 2008 15:56:36
Anne & Lynn Wheeler <lynn@garlic.com> writes:
the risk isn't reduced by securing all possible breaches and/or all
possible other points where crooks might be able to obtain the
information ... for complete end-to-end security ... as per the
requirement placed on the x9a10 financial standard working group to
preseve the integrity of the financial infrastructure for *ALL* retail
payments ... in x9.59 financial standard protocol, the risk is reduced
by eliminating the crooks being able to use the information for
fraudulent transactions.
re:
http://www.garlic.com/~lynn/2008.html#2 folklore indeed
http://www.garlic.com/~lynn/2008.html#4 folklore indeed
http://www.garlic.com/~lynn/2008.html#5 folklore indeed
for other x9a10 financial standard working group and
x9.59 financial standard folklore
http://www.garlic.com/~lynn/x959.html#x959
and
http://www.garlic.com/~lynn/subpubkey.html#x959
x9.59 given the requirement to address *ALL* retail payments had to look
seriously at all possible compromises in all possible environments
... not just simple point solution in single specific environments.
as mentioned in some recent posts ... some of the other solutions
from the period had enormous payload and processing bloat
http://www.garlic.com/~lynn/2007v.html#64 folklore indeed
and/or were so myopically focused on particular point solution
actually managed to reduce the integrity of the overall,
end-to-end infrastructure
http://www.garlic.com/~lynn/aadsm28.htm#1
part of x9.59 standard was to require strong authentication
for every transactions ... as means of eliminating the enormous
number of vulnerabilities inherit in the existing paradigm
associated with the naked transaction metaphor
http://www.garlic.com/~lynn/subintegrity.html#payments
so one of the mechanism for strong authentication involved digital
signatures ... but the genre from the period was to append a digital
certificate to every digital signature. The associated digital
certificate paradigm was one of the things that contributed to some of
the enormous payload and processing bloats
http://www.garlic.com/~lynn/subpubkey.html#bloat
The x9a10 proposed a much simpler processing paradigm with
digital signatures that didn't require the enormous additional
processing and payload bloat represented by the digital
certificate processing
http://www.garlic.com/~lynn/subpubkey.html#certless
this created some amount of contention among standard body members who
were strongly oriented towards digital certificate paradigm ... and
there was strong on going effort to make x9.59 standard mandate digital
certificates (which contributed to delays in getting the standard
finally passed).
however the significant processing and payload bloat that
resulted from digital certificates was a well known fact. as a result,
there was a standardization effort started in x9 for financial
transaction compressed digital certificates (addressing at least the
enormous payload bloat problem, with objective of reducing the
enormous payload bloat from a factor of one hundred times to
possibly only five times)
after awhile, i proposed that it was possible to take their compression
principles and compress a financial transaction digital certificate to
zero bytes. then, instead stating that x9.59 transaction would not need
an appended digital certificate (as a means of avoiding the enormous
payload and processing bloat), the standard could state that x9.59
transaction standard mandated that every transaction have an appended
zero-byte digital certificate.
past posts describing zero-byte digital certificates and/or how to
create zero-byte digital certificates:
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss6 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm4.htm#6 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment Standard
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
http://www.garlic.com/~lynn/aadsm9.htm#softpki23 Software for PKI
http://www.garlic.com/~lynn/aadsm12.htm#28 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#64 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
http://www.garlic.com/~lynn/aadsm14.htm#30 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/aadsm14.htm#41 certificates & the alternative view
http://www.garlic.com/~lynn/aadsm20.htm#11 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm22.htm#4 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm23.htm#51 Status of opportunistic encryption
http://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
http://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game
http://www.garlic.com/~lynn/2000b.html#93 Question regarding authentication implementation
http://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#3 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
http://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2004d.html#7 Digital Signature Standards
http://www.garlic.com/~lynn/2004j.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#7 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#8 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#9 Smart card Authentification
http://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for offline solution
http://www.garlic.com/~lynn/2005o.html#31 Is symmetric key distribution equivalent to symmetric key generation?
http://www.garlic.com/~lynn/2005t.html#6 phishing web sites using self-signed certs
http://www.garlic.com/~lynn/2006b.html#37 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#35 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#8 Beginner's Pubkey Crypto Question
http://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#31 X.509 and ssh
http://www.garlic.com/~lynn/2006h.html#28 confidence in CA
http://www.garlic.com/~lynn/2006i.html#13 Multi-layered PKI implementation
http://www.garlic.com/~lynn/2007h.html#31 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007l.html#16 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007q.html#72 Value of SSL client certificates?
folklore indeed
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: folklore indeed
Newsgroups: alt.folklore.computers
Date: Tue, 01 Jan 2008 15:56:36
Anne & Lynn Wheeler <lynn@garlic.com> writes:
the risk isn't reduced by securing all possible breaches and/or all
possible other points where crooks might be able to obtain the
information ... for complete end-to-end security ... as per the
requirement placed on the x9a10 financial standard working group to
preseve the integrity for *ALL* retail payments ... in x9.59 financial
standard protocol, the risk is reduced by eliminating the crooks being
able to use the information for fraudulent transactions.
re:
http://www.garlic.com/~lynn/2008.html#2 folklore indeed
http://www.garlic.com/~lynn/2008.html#4 folklore indeed
http://www.garlic.com/~lynn/2008.html#5 folklore indeed
for other x9a10 financial standard working group and
x9.59 financial standard folklore
http://www.garlic.com/~lynn/x959.html#x959
and
http://www.garlic.com/~lynn/subpubkey.html#x959
x9.59 given the requirement to address *ALL* retail payments had to look
seriously at all possible compromises in all possible environments
... not just simple point solution in single specific environments.
as mentioned in some recent posts ... some of the other solutions
from the period had enormous payload and processing bloat
http://www.garlic.com/~lynn/2007v.html#64 folklore indeed
and/or were so myopically focused on particular point solution
actually managed to reduce the integrity of the overall,
end-to-end infrastructure
http://www.garlic.com/~lynn/aadsm28.htm#1
part of x9.59 standard was to require strong authentication
for every transactions ... as means of eliminating the enormous
number of vulnerabilities inherit in the existing paradigm
associated with the naked transaction metaphor
http://www.garlic.com/~lynn/subintegrity.html#payments
so one of the mechanism for strong authentication involved digital
signatures ... but the genre from the period was to append a digital
certificate to every digital signature. The associated digital
certificate paradigm was one of the things that contributed to some of
the enormous payload and processing bloats
http://www.garlic.com/~lynn/subpubkey.html#bloat
The x9a10 proposed a much simpler processing paradigm with
digital signatures that didn't require the enormous additional
processing and payload bloat represented by the digital
certificate processing
http://www.garlic.com/~lynn/subpubkey.html#certless
this created some amount of contention among standard body members who
were strongly oriented towards digital certificate paradigm ... and
there was strong on going effort to make x9.59 standard mandate digital
certificates (which contributed to delays in getting the standard
finally passed).
however the significant processing and payload bloat that resulted from
digital certificates was a well known fact. as a result, there was a
standardization effort started in x9 for "compressed" digital
certificates (addressing at least the enormous payload bloat problem).
after awhile, i proposed that it was possible to take their compression
principles and compress a financial transaction digital certificate to
zero bytes. then, instead stating that x9.59 transaction would not need
an appended digital certificate (as a means of avoiding the enormous
payload and processing bloat), the standard could state that x9.59
transaction standard mandated that every transaction have an appended
zero byte digital certificate.
past posts describing zero byte digital certificates and/or how to
create zero byte digital certificates:
http://www.garlic.com/~lynn/aadsm3.htm#cstech3 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#cstech6 cardtech/securetech & CA PKI
http://www.garlic.com/~lynn/aadsm3.htm#kiss1 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm3.htm#kiss6 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aadsm4.htm#6 Public Key Infrastructure: An Artifact...
http://www.garlic.com/~lynn/aadsm4.htm#9 Thin PKI won - You lost
http://www.garlic.com/~lynn/aadsm5.htm#x959 X9.59 Electronic Payment Standard
http://www.garlic.com/~lynn/aadsm5.htm#shock revised Shocking Truth about Digital Signatures
http://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
http://www.garlic.com/~lynn/aadsm9.htm#softpki23 Software for PKI
http://www.garlic.com/~lynn/aadsm12.htm#28 Employee Certificates - Security Issues
http://www.garlic.com/~lynn/aadsm12.htm#64 Invisible Ink, E-signatures slow to broadly catch on (addenda)
http://www.garlic.com/~lynn/aadsm13.htm#20 surrogate/agent addenda (long)
http://www.garlic.com/~lynn/aadsm14.htm#30 Maybe It's Snake Oil All the Way Down
http://www.garlic.com/~lynn/aadsm14.htm#41 certificates & the alternative view
http://www.garlic.com/~lynn/aadsm20.htm#11 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm22.htm#4 GP4.3 - Growth and Fraud - Case #3 - Phishing
http://www.garlic.com/~lynn/aadsm23.htm#51 Status of opportunistic encryption
http://www.garlic.com/~lynn/aadsm24.htm#5 New ISO standard aims to ensure the security of financial transactions on the Internet
http://www.garlic.com/~lynn/aadsm27.htm#35 The bank fraud blame game
http://www.garlic.com/~lynn/2000b.html#93 Question regarding authentication implementation
http://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#3 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
http://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation practicalities
http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2004d.html#7 Digital Signature Standards
http://www.garlic.com/~lynn/2004j.html#6 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#7 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#8 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004j.html#9 Smart card Authentification
http://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for offline solution
http://www.garlic.com/~lynn/2005o.html#31 Is symmetric key distribution equivalent to symmetric key generation?
http://www.garlic.com/~lynn/2005t.html#6 phishing web sites using self-signed certs
http://www.garlic.com/~lynn/2006b.html#37 X.509 and ssh
http://www.garlic.com/~lynn/2006c.html#35 X.509 and ssh
http://www.garlic.com/~lynn/2006e.html#8 Beginner's Pubkey Crypto Question
http://www.garlic.com/~lynn/2006f.html#29 X.509 and ssh
http://www.garlic.com/~lynn/2006f.html#31 X.509 and ssh
http://www.garlic.com/~lynn/2006h.html#28 confidence in CA
http://www.garlic.com/~lynn/2006i.html#13 Multi-layered PKI implementation
http://www.garlic.com/~lynn/2007h.html#31 sizeof() was: The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007l.html#16 John W. Backus, 82, Fortran developer, dies
http://www.garlic.com/~lynn/2007q.html#72 Value of SSL client certificates?
folklore indeed
Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: folklore indeed
Newsgroups: alt.folklore.computers
Date: Wed, 02 Jan 2008 10:33:43
Anne & Lynn Wheeler <lynn@garlic.com> writes:
also as referenced in previous posts ... the national retailers
federation have raised the issue of changing the retention mandates.
http://www.garlic.com/~lynn/aadsm27.htm#60 Retailers try to push data responsibilities back to banks
there is some conjecture that the financial institutions may resist
becoming responsible for the transaction activity respository with
lots of distributed access from their retailers and merchants ...
since there would be a huge number of breach opportunities
(represented by all those authorized accesses) and the financial
institution then becomes liable (rather than the merchant for the
breach).
re:
http://www.garlic.com/~lynn/2008.html#5 folklore indeed
a couple recent item:
Issuers Line Up for TJX Settlements
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=11992194668314718872&block=
TJX To Pay Banks Up To $41 Million After Data-Theft Breach
http://money.cnn.com/news/newsfeeds/articles/djf500/200712201826DOWJONESDJONLINE001104_FORTUNE5.htm
...
as stated before, the "risk" isn't the actual breach, the "risk" is that
the crooks can use the harvested information (regardless of how they
obtained it; skimming, breaches, evesdropping, etc) for fraudulent
transactions.
the x9a10 financial standard working group, in the mid-90s, having been
given the requirement to preserve the integrity of the financial
infrastructure for all retail payments, did detailed end-to-end
vulnerabiilty and threat assessment. the resulting x9.59 financial
standard:
http://www.garlic.com/~lynn/x959.html#x959
didn't do anything about reducing skimming, breaches, evesdropping, etc.
what x9.59 standard did was eliminate the usefullness of that
information to the crooks for executing fraudulent transactions.
this somewhat is discussed in various postings in the *naked transaction
metaphor* threads ... instead of requiring that all access to the
information is totally eliminated ... eliminating the ability to use the
information for fraud.
http://www.garlic.com/~lynn/subintegrity.html#payments
this is also the periodic observation that even if the planet were
buried under miles of (information hiding) encryption, it still wouldn't
be able to prevent the information leakage. part of this is the dual-use
characterization/requirements placed on the information. from one
standpoint, the information has to be readily available for numerous
business processes (and by a large number of different people). from
the other standpoint (since in the current paradigm, the information can
be used by crooks for fraudulent transactions), the information has to
be kept confidential and never divulged (to anybody). recent post
mentioning burying the planet under miles of encryption and
still not being able to prevent information leakage
http://www.garlic.com/~lynn/2007v.html#70 folklore indeed
we had been called in to consult with small client/server startup that
wanted to do payment transactions on their servers. they also had this
technology they invented, called SSL they wanted to use for the
transactions. the result is now frequently called electronic commerce.
http://www.garlic.com/~lynn/subnetwork.html#gateway
even before getting involved with x9a10 financial standard working
group, we realized that the information was extremely vulnerability and
we proposed that everybody with any kind of access to transaction
information, be required to at least have an FBI background check ... in
part because it had been known for a long time, that the highest
percentage of related fraud has involved insiders. recent post
mentioning insider issue
http://www.garlic.com/~lynn/2007v.html#74 folklore indeed
since FBI background check pretty much met all merchant employees
... it didn't get very far.
a few old posts mentioning the FBI background check requirement
http://www.garlic.com/~lynn/aadsm6.htm#terror3 [FYI] Did Encryption Empower These Terrorists?
http://www.garlic.com/~lynn/aadsm21.htm#20 Some thoughts on high-assurance certificates
http://www.garlic.com/~lynn/aadsm21.htm#34 X.509 / PKI, PGP, and IBE Secure Email Technologies
http://www.garlic.com/~lynn/aadsm22.htm#18 "doing the CA statement shuffle" and other dances
http://www.garlic.com/~lynn/2001j.html#5 E-commerce security????
http://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean Anything?
http://www.garlic.com/~lynn/2005v.html#4 ABN Tape - Found
http://www.garlic.com/~lynn/2006.html#33 The new High Assurance SSL Certificates
http://www.garlic.com/~lynn/2006d.html#28 Caller ID "spoofing"
http://www.garlic.com/~lynn/2006d.html#30 Caller ID "spoofing"
http://www.garlic.com/~lynn/2007b.html#8 Special characters in passwords was Re: RACF - Password rules
http://www.garlic.com/~lynn/2007c.html#6 Securing financial transactions a high priority for 2007
For the History buff's an IBM 5150 pc
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: For the History buff's an IBM 5150 pc
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 02 Jan 2008 16:16:14
barry.a.schwarz@BOEING.COM (Schwarz, Barry A) writes:
The Apple I went on sale in l976 so the author seems to have limited
view of what a PC is.
5100 pc was announced sep75.
http://www-03.ibm.com/ibm/history/exhibits/pc/pc_2.html
predating the 5150 pc in 1981.
http://www-03.ibm.com/ibm/history/exhibits/pc/pc_1.html
from above:
One of the earliest IBM attempts to move computing into the hands of
single users was the "SCAMP" project in 1973. This six-month development
effort by the company's General Systems Division (GSD) produced a
prototype device dubbed "Special Computer, APL Machine Portable" (SCAMP)
that PC Magazine in 1983 called a "revolutionary concept" and "the
world's first personal computer." To build the prototype in the short
half-year allowed, its creators acquired off-the-shelf materials for
major components. SCAMP could be used as a desktop calculator, an
interactive APL programming device and as a "dispenser" of canned
applications. The successful demonstration of the prototype in 1973 led
to the launch of the IBM 5100 Portable Computer two years later.
... snip ...
of course, one could claim that work by science center
http://www.garlic.com/~lynn/subtopic.html#545tech
creating cp67 virtual machines in the mid-60s, enabled the deployment of
CMS personal computing.
Information security breaches quadrupled in 2007
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Information security breaches quadrupled in 2007
Newsgroups: alt.folklore.computers
Date: Wed, 02 Jan 2008 16:41:24
so much for "Securing financial transactions a high priority for 2007".
Information security breaches quadrupled in 2007
http://www.theregister.co.uk/2008/01/02/data_breaches_skyrocket/
recent posts mentioning that change in paradigm may be necessary:
http://www.garlic.com/~lynn/aadsm28.htm#6 Death of antivirus software imminent
and
http://www.garlic.com/~lynn/aadsm28.htm#7 Why Security Modelling doesn't work -- the OODA-loop of today's battle
using the metaphor that the current situation doesn't provide a
easily/readily defensable position ... applying a Boyd perspective
... what would be necessary to choose/create defensible position.
other
http://www.garlic.com/~lynn/aadsm28.htm#0 2007: year in review
and of course past posts mentioning Boyd
http://www.garlic.com/~lynn/subboyd.html#boyd
No Glory for the PDP-15
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: No Glory for the PDP-15
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Wed, 02 Jan 2008 19:25:47
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
Supposedly when asked what they would have done differently
to unix many years later, the answer was to write "creat"
with an "e". More commands and functions might have had
longer names, but the basic idea of a simple OS might
still have occurred.
similar but different thread from crypto mailing list, virtual machine
operating system as a simple/micro kernel ... also mentioning vax/vms
vmm
http://www.garlic.com/~lynn/aadsm28.htm#4 Death of antivirus software iminent
http://www.garlic.com/~lynn/aadsm28.htm#6 Death of antivirus software iminent
http://www.garlic.com/~lynn/aadsm28.htm#8 Death of antivirus software iminent
LINC-8 Front Panel Questions
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: LINC-8 Front Panel Questions
Newsgroups: alt.folklore.computers
Date: Wed, 02 Jan 2008 20:33:39
John Byrns <byrnsj@sbcglobal.net> writes:
How do you know what will be considered "outdated" by future users?
i had done the original cmsback implementation ... misc. old email
http://www.garlic.com/~lynn/lhwemail.html#cmsback
which then went thru a number of iterations as workstation datasave,
adsm, and currently tsm
http://www-306.ibm.com/software/tivoli/products/storage-mgr/
misc. backup/archive postings
http://www.garlic.com/~lynn/subtopic.html#backup
on the other hand ... never anticipated the problem recently mentioned
here involving loosing large amounts of archived data some dating
back to my undergraduate days in the 60s:
http://www.garlic.com/~lynn/2007u.html#29 Folklore references to CP67 at Lincoln Labs
hacked TOPS-10 monitors
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: hacked TOPS-10 monitors
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Thu, 03 Jan 2008 10:45:31
cstacy@news.dtpq.com (Christopher C. Stacy) writes:
I had always heard that most sites ran a hacked
version of TOPS-10 ("nobody runs a vanilla monitor").
How true was that?
I also believe it was not uncommon for IBM sites
to fiddle with the provided software.
My experience with either of those systems was
linited to a few sites, though, so I may have
a distorted impression.
it was especially true of cp67 and vm370 ... both shipped not only with
source, but the maintenance was also done in source. slightly related
recent post
http://www.garlic.com/~lynn/2007u.html#29 Folklore references to CP67 at Lincoln Labs
it was less true of the other systems ... since they didn't ship as
source distribution ... although source listings were available.
this changed in the early 80s with the transition to OCO (object code
only); recent posts mentioning OCO
http://www.garlic.com/~lynn/2007u.html#8 Open z/Architecture or Not
http://www.garlic.com/~lynn/2007u.html#9 Open z architecture and Linux questions
in the middle of the OCO wars there was some analysis of (waterloo)
"SHARE" library for vm370 ... that there was a many lines of source in
the "SHARE" library ... as there was in the base product. ... recent
post mentioning share (source) library:
http://www.garlic.com/~lynn/2007n.html#3 Is Parallel Programming Just Too Hard?
part of the corporate transition to OCO was to provide "user exits" ...
places where users could add calleable routines associated with specific
functions.
in recent thread in crypto mailing lists ... there were comments about
early systems not being built specifically for "security". recent
reference
http://www.garlic.com/~lynn/2008.html#12 No Glory for the PDP-15
and posts
http://www.garlic.com/~lynn/aadsm28.htm#4 Death of antivirus software iminent
http://www.garlic.com/~lynn/aadsm28.htm#6 Death of antivirus software iminent
http://www.garlic.com/~lynn/aadsm28.htm#8 Death of antivirus software iminent
however, the idea that a system that didn't provide security was sort of
a foreign concept ... and therefor having to build a separate system
specifically for security (because normal systems didn't provide
security) was also a foreign concept.
besides the gov. and commercial institutions with high integrity
requirements there were also commercial timesharing (cp67 & vm370 based)
service bureaus
http://www.garlic.com/~lynn/subtopic.html#timeshare
and one of the things that they would do, was make cms "padded cell"
modifications to limit the harm that users might do themselves (as
opposed to underlying security that limited harm that they could do the
system or each other).
one example of the level of security ... is some of these commercial
timesharing service bureaus were providing services to competitive wall
street firms (all on the same machine).
hacked TOPS-10 monitors
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: hacked TOPS-10 monitors
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Thu, 03 Jan 2008 18:59:14
Peter Flass <Peter_Flass@Yahoo.com> writes:
I'd say *everyone* had mods to HASP/JES2, which is why so much of it
is still shipped as source. I think most people modified VM, though
Lynne could speak to this better. OS/360, MVS, etc. tried to provide
standard exit points. Most people customized one or more exits,
though I don't know if you'd classify these as a system mod.
re:
http://www.garlic.com/~lynn/2008.html#14 hacked TOPS-10 monitors
I had also done significant amount of HASP mods. as undergraduate. One
was deleting the RJE support (to recover some space) and replacing it
with 2741 & tty terminal support and a editor that implemented CMS edit
syntax (total different code since cms editor wasn't re-entrant ... and
HASP code had to be re-entrant) ... for an early CRJE
later in the transition from HASP to JES2 (and move to gburg, i've
mentioned before my wife did a stint in the gburg JES group after
working on future system project) ... JES2 had some integration and
distribution problems. The JES2 was doing much of their source
management with the cp67/vm370 processes on CMS ... but then to ship,
they had to convert to "MVS" process.
misc. past posts mentioning hasp, jes, nje, etc
http://www.garlic.com/~lynn/subtopic.html#hasp
No Glory for the PDP-15
Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: No Glory for the PDP-15
Newsgroups: alt.folklore.computers
Date: Fri, 04 Jan 2008 10:15:04
jmfbahciv writes:
Consider a personality trait where the person has to control
all aspects of a thing. When writing OS code this type
of personality will be annoyed, irritated, and dismissive
of an interruption. So the code won't reflect true timesharing
which is event-based. You would tend to see an OS that is
task-based instead. An interruption would be put on list
to be dealt with after the current task is 100% finished.
we've had this discussion in past threads ... in other threads i've
characterized it as not being able to change coding styles when dealing
with different types of operations ... device drviers tend to be very
event driven ... but I've critized before purely event driven (device
driver) coding styles in schedulers ... which can work much better if it
is dealing more with statistical activity.
this is also related to a joke that i buried in my resource manager.
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock
the litigation from commerical and gov. resulted in the 23jun69
unbundling announcement
http://www.garlic.com/~lynn/subtopic.html#unbundle
which started to charge for application software and other services.
however, the case was made that kernel software was still free. cp67
and vm370 continued full source-based distribution and maintenance.
however, the distraction of the future system effort
http://www.garlic.com/~lynn/subtopic.html#futuresys
and a period where products in the 370 pipeline started to dry up
... allowed clone processors to gain a foothold. i claim that then
contributed to the decision to start charging for kernel software
... and the release of my resource manager was selected to be the guinea
pig. however, even with starting to charge for all software ... there
was still a period before the decision to go OCO (object code only)
... recent reference:
http://www.garlic.com/~lynn/2008.html#14 hacked TOPS-10 monitors
a lot of resource manager was low level event oriented coding ... that
permeated all thru the kernel (pathlength optimizatins, fault handling,
elimination of conditiions to leading to zombies, kernel strucutre reorg
anticipating multiprocessor support) ... however, the stated purpose for
the resource manager was advanced dynamic adaptive capability.
one of the corporate revues came up with the state-of-the-art for all
"modern" schedulers was low-level "tuning" knobs. this totally ignored
all the code that monitored all the low-level operational
characteristics and dynamically adapted to configuration and workload.
So i had to add low-level "tuning" knobs to be considered
"state-of-the-art".
documentation was provided describing exactly what the tuning knobs did
as well as the "algorithms" behind what went on ... as well as all the
code was available.
the joke? (which went undetected for decades?) was what operations
research call "degrees of freedom" ... i.e. the dynamic adaptive code
had more "degrees of freedom" than the tuning knobs. one of my
characterizations was that the typical people dealing with low-level
kernel code (in 360 assembler) didn't recognize something that was
effectively dealing in time dimension.
misc past posts mentioning tuning knobs:
http://www.garlic.com/~lynn/97.html#12 OSes commerical, history
http://www.garlic.com/~lynn/2002c.html#13 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002c.html#16 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002c.html#28 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2004o.html#10 Multi-processor timing issue
http://www.garlic.com/~lynn/2005b.html#58 History of performance counters
http://www.garlic.com/~lynn/2006b.html#21 IBM 3090/VM Humor
http://www.garlic.com/~lynn/2007g.html#56 The Perfect Computer - 36 bits?
Usefulness of bidirectional read/write?
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Usefulness of bidirectional read/write?
Newsgroups: alt.folklore.computers
Date: Fri, 04 Jan 2008 19:22:54
"Rostyslaw J. Lewyckyj" <urjlew@bellsouth.net> writes:
IBM or SYNCSORT?
Also although it was no rewind required, it wasn't read backwards!
It was backspace a block and then read it forward in the normal
direction. Probably : (a)backspace, (b)wait, (c)read block,
(d) backspace two blocks, GOTO (b). That way the tape motion
back was overlapped with processing.
I.e. I don't believe there was physical backward reading
into a buffer or such like.
as before, quick & dirty conversion of gcard ios3270 to html
http://www.garlic.com/~lynn/gcard.html
and magnetic tape i/o command codes
http://www.garlic.com/~lynn/gcard.html#25
from above (dates to 360 2400 tape drives)
I/O Command Codes Magnetic-Tape
+-----------------------------------+------------------------------------+
| Write 01 | Sense 04 |
| Write Tape Mark 0F | Request Track-in-Error 1B |
| | Erase Gap 17 |
| Read Forward 02 | |
| Read Backward 0C | Mode Set 2 (9-track) |
| | 800 BPI CB |
| Backspace Block 27 | 1600 BPI C3 |
| Backspace File 2F | 6250 BPI (3420) D3 |
| Forward Space Block 37 | |
| Forward Space File 3F | Sense Reserve (3420) F4 |
| | Sense Release (3420) D4 |
| Rewind 07 | |
| Rewind Unload 0F | Loop Write-to-Read (3420) 8B |
| | Set Diagnose (3420) 4B |
| Data Secrity Erase (3420) 97 | Diagnostic Mode Set (3420) 0B |
+-----------------------------------+------------------------------------+
... snip ...
both read forward and read backward ... also mentioned here:
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_2401.html
for even older ... IBM 7340 hypertape drive (circa 1961)
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_7340.html
from above:
Among the 7340's features were:
* Character rate -- As many as 340,000 decimal digits per second;
170,000 alphanumeric characters per second.
* Checking -- Error detection and correction, dual odd-parity
checking. A new, highly reliable method of recording called "IBM
Phase Encoding" was used.
* Reel Capacity -- In many applications, more than twice that of the
IBM 729-IV reels (recorded at high density).
* Cartridges for Tape Reels -- Supply and take-up reels in a sealed
cartridge; faster loading and unloading (no manual threading of
tape), tape protected from contamination and operator damage,
unload reel without rewinding at any point in the file.
* Read Backward -- No rewinding necessary between passes in Phase II
of tape sorting, faster tape searching.
* Faster Access Times -- 4.2 milliseconds (average).
* File Protection -- Cartridge file protect device was under program control.
... snip ...
predates syncsort.
following:
http://www.softwarehistory.org/history/important_people.html
mentions Aso Tavitian co-founded Syncsort in 1969.
for a little topic drift, above, also mentions that Bob Weissman was
president of National CSS (cp67, virtual machine commercial timesharing
service bureau) when it was acquired by D&B ... subsequently became
president of D&B. some posts mentioning virtual machine timesharing
service bureau
http://www.garlic.com/~lynn/subtopic.html#timeshare
my first programming job as undergraduate was doing a port of 1401
MPIO program to 360/30. The univ. had 709 for running most of its
workload ... but used a 1401 for driving unit record equipment and
transfers to/from tape (with tapes manually carried between 1401 and
709).
the 360/30 was brought in to replace 1401 as part of transition to
replacing the 709 ... and the 360/30 could perfectly well run the MPIO
in 1401 hardware emulatiion mode ... but the port supposedly was part
of gaining 360 experience.
as part of the port to 360/30, i implemented multiple buffering ...
using all real storage that was available ... being able to overlap
transfer to/from tape with unit record i/o.
Remembering the Cray-1
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Remembering the Cray-1
Newsgroups: alt.folklore.computers
Date: Fri, 04 Jan 2008 20:58:29
Remembering the Cray-1
http://www.theregister.co.uk/2008/01/05/tob_cray1/
the above webpage (for tomorrow, 5 Jan 2008) also mentions:
Related stories
• Remembering the CDC 6600 (3 December 2007)
http://www.theregister.co.uk/2007/12/03/tob_cdc_6600/
• Remembering the IBM PC (17 November 2007)
http://www.theregister.co.uk/2007/11/17/tob_ibm_personal_computer/
• Remembering the Commodore PET 2001 (10 November 2007)
http://www.theregister.co.uk/2007/11/10/tob_commodore_pet_2001/
... on the other hand, this particular news organization has been
listing multiple virtualization (the "new", 40+ yr old) URLs on
nearly all of their webpages for some time.
Tap and faucet and spellcheckers [was: Re: What do YOU call
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Tap and faucet and spellcheckers [was: Re: What do YOU call
Newsgroups: alt.usage.english,alt.folklore.computers
Date: Fri, 04 Jan 2008 22:14:10
Lon Stowell <lon.stowell@comcast.net> writes:
I can remember a rule a long time ago, that field engineers should
not, by themselves, ever perform a field wiring change where more than
8 successive items had to be modified, because the odds after that
were almost even that they would make a mistake. This was in RCA
Computer System customer service, where this may just have been a
corruption of Amdahl's Law [which I heard much more about while
employed at Pyramid than at Amdahl]
even worse, one of the 370 clones makers had forgetten(?) to keep
detailed manufacturing records ... then it sort of hit the fan when they
had a couple hundred machines in the field ... at dozens of different
engineering levels ... creating a real maintenance nightmare.
old email reference
http://www.garlic.com/~lynn/2006b.html#email800310
in this post:
http://www.garlic.com/~lynn/2006b.html#39 another blast from the past
old email has a little topic drift x-over with this recent post:
http://www.garlic.com/~lynn/2008.html#17 Usefulness of bidirectional read/write?
the old email also has mention of inquiry by tso product
executive asking me if i would consider implementing my resource
manager in mvs ... slight topic drift x-over with this recent post:
http://www.garlic.com/~lynn/2008.html#16 No Glory for the PDP-15
of course other comments (in the old email) about cms (personal &
interactive computer) and tso (interactive? computing) being in
different divisions and each division needing their "own" offering is
quite contrived ... since earlier the "TSO" division had done its
best to totally kill off the whole vm370 product ... transferring all
the people to POK to assist in helping get out mvs/xa on schedule
... recent post with reference:
http://www.garlic.com/~lynn/2007v.html#96 source for VAX programmers
http://www.garlic.com/~lynn/2007v.html#100 source for VAX programmers
Tap and faucet and spellcheckers [was: Re: What do YOU call
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Tap and faucet and spellcheckers [was: Re: What do YOU call
Newsgroups: alt.usage.english,alt.folklore.computers
Date: Sat, 05 Jan 2008 00:49:34
Lon Stowell <lon.stowell@comcast.net> writes:
I can remember a rule a long time ago, that field engineers should
not, by themselves, ever perform a field wiring change where more than
8 successive items had to be modified, because the odds after that
were almost even that they would make a mistake. This was in RCA
Computer System customer service, where this may just have been a
corruption of Amdahl's Law [which I heard much more about while
employed at Pyramid than at Amdahl]
something jogged my mind about pyramid ... there was a company that had
been running some sort of online service on pyramid computers and then
made a move to get into e-commerce business ("oneserver") .. they were
half a block or so down the road from netscape ... part way between them
and 101 on ellis. My impression they had some number of pyramid and
oracle folks.
not having much success trying find something on the web of their
connection to pyramid and/or the pre e-commerce business. did find a
reference that one of their directors had been chairman and ceo of
pyramid from 86 until 95 when it was acquired by siemens.
after doing the thing with the "small" client/server startup ... up the
street from them ... for what is frequently now called e-commerce
http://www.garlic.com/~lynn/subnetwork.html#gateway
... we then were asked in to spend some time with some number of the
other companies in the area.
this is later reference ...
http://www.internetnews.com/ec-news/article.php/242421
one earlier reference:
Founded: 1987
Business description: ConnectInc.com private computer networks called
the CONNECT online information services delivery systems and electronic
commerce applications.
...
one of the issues is that the coming of the internet made the (private)
value added networks (VANs) that were springing up in the 80s (some
earlier), obsolete.
No Glory for the PDP-15
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: No Glory for the PDP-15
Newsgroups: alt.folklore.computers
Date: Sat, 05 Jan 2008 12:38:28
jmfbahciv writes:
There seem to be a lot of people who cannot consider time as
a dimension. I've never understood this one. When I talk
about bit flows and work flows, I'm using time as a primary
dimension. Note that I see Boyd's theory is based on flowing water
models.
re:
http://www.garlic.com/~lynn/2008.html#16 No Glory for the PDP-15
recent thread in financial crypto blog mentioning Boyd and
(boyd's) OODA-loops
http://www.garlic.com/~lynn/aadsm28.htm#3 Why Security Modelling doesn't work -- the OODA-loop of today's battle
http://www.garlic.com/~lynn/aadsm28.htm#5 Why Security Modelling doesn't work -- the OODA-loop of today's battle
http://www.garlic.com/~lynn/aadsm28.htm#7 Why Security Modelling doesn't work -- the OODA-loop of today's battle
http://www.garlic.com/~lynn/aadsm28.htm#10 Why Security Modelling doesn't work -- the OODA-loop of today's battle
lots of past posts mentioning boyd
http://www.garlic.com/~lynn/subboyd.html#boyd
and various URLs from around the web mentioning boyd
and/or OODA-loops
http://www.garlic.com/~lynn/subboyd.html#boyd2
z/OS and VM Control Blocks
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: z/OS and VM Control Blocks
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sat, 05 Jan 2008 16:28:25
lindy.mayfield@SSF.SAS.COM (Lindy Mayfield) writes:
It was only a question! (-: I certainly didn't mean to upset the status
quo. ((--::
recent post from how i tried to handle it long ago and far away
... before OCO in a ipcs alternative that i had implemented in rex(x).
http://www.garlic.com/~lynn/2007v.html#46 folklore indeed
it was eventually in use by all internal locations and PSRs ... even tho
there was a decision not to release it to customers.
http://www.garlic.com/~lynn/subtopic.html#dumprx
it sort-of started out as a demonstration of the functionality of the
"new" rex ... the stated objective was in half-time over period of
3months, i would re-implement ipcs in rex(x) with ten times the function
and it would run ten times faster (little slight of hand since the base
ipcs was all implemented in assembler).
i had access to softcopy of all the base source files (including control
block definitions) and documentation. however, nearly all this stuff had
been created for hardcopy/printed output. the particular issue was how
to come up with online appropriate information display including being
able to tailor to problem being dealt with (very crude online context
sensitive orientation).
Need Help filtering out sporge in comp.arch
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Need Help filtering out sporge in comp.arch
Newsgroups: alt.folklore.computers
Date: Sat, 05 Jan 2008 19:44:50
ArarghMail801NOSPAM writes:
And here I thought it stood for "Program Temporary Fix". :-)
IBM Program temporary fix
http://en.wikipedia.org/wiki/Program_temporary_fix
from above:
Program temporary fix is the standard IBM locution to designate single
bugfix or group of bugfixes distributed in a form ready to install for
customers. Often cited tongue-in-cheek as Permanent Temporary Fix.
... snip ...
also reference here ...
Using the program temporary fix (PTF) functions
http://publib.boulder.ibm.com/iseries/v5r2/ic2924/books/c415321212.htm
for other topic drift, recent post mentioning vm370 source
update/maintenance
http://www.garlic.com/~lynn/2007u.html#6 Open z/Architecture or Not
http://www.garlic.com/~lynn/2007u.html#8 Open z/Architecture or Not
http://www.garlic.com/~lynn/2008.html#14 hacked TOPS-10 monitors
http://www.garlic.com/~lynn/2008.html#16 No Glory for the PDP-15
in vm370, each PTF was a separate source file "update" (one per source
module needing update).
once a month, all accumlated PTFs and some set of lesser enhancements
would be packaged ... with some amount of regression testing into a PLC
(program level change) tape ... and distributed to customers.
there might be a major release about once a year ... where all
accumulated source updates and other functional enhancements would be
integrated with the base source module and distributed (on tape).
a "kernel" map consisted of listing of location of each module in fixed
kernel memory ... as well as the base (assembler) source file along with
date/time ... as well as naming of all individual source update files
(along with date/time) that went into creating the final source that
went into generating the executable image for that routine.
in the mid-80s, i was on business trip visiting the madrid science
center ... they had a project scanning and digitizing a lot of old
documents ... in preparation for 500 yr anniv. "discovery" of
america. while there, i visited local movie house ... which included
short film produced at the univ. one scene played major role with wall
covered with possible 20 or so televisions ... all scrolling identical
text (approx. 1200 baud?). it took me a short while to realize that it
was continously looping display of a vm370 kernel "map". What was
worse, i realized I recognized the PLC of the kernel ... by which
PTFs were and were not included.
misc. past posts mentioning visiting madrid science center:
http://www.garlic.com/~lynn/99.html#9 IBM S/360
http://www.garlic.com/~lynn/2000.html#14 Computer of the century
http://www.garlic.com/~lynn/2000g.html#36 stupid user stories
http://www.garlic.com/~lynn/2001e.html#66 line length (was Re: Babble from "JD" <dyson@jdyson.com>)
http://www.garlic.com/~lynn/2001n.html#16 Movies with source code (was Re: Movies with DEC minis)
http://www.garlic.com/~lynn/2002h.html#35 Computers in Science Fiction
http://www.garlic.com/~lynn/2002n.html#39 CMS update
http://www.garlic.com/~lynn/2004g.html#40 IBM 7094 Emulator - An historic moment?
http://www.garlic.com/~lynn/2004h.html#17 Google loves "e"
Tap and faucet and spellcheckers
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Tap and faucet and spellcheckers
Newsgroups: alt.usage.english,alt.folklore.computers
Date: Sat, 05 Jan 2008 09:47:22
Peter Moylan <peter@DIESPAMMERSDIEpmoylan.org> writes:
One bit of (relatively) new computer jargon that still annoys me is
"stable". We used to call software stable if it no longer needed to be
modified. The new name for that is "abandonware". If I don't release a
new version of my own software at least once every few months - even if
that release is not an improvement - I get requests to release it into
the public domain on the grounds that I'm no longer "supporting" (a
euphemism for "changing") it.
When people call a version of a program stable now, it means that it
doesn't fall over very often. The definition in everyone's mind is
probably something like (MTBF > 1 week).
in the 80s and early 90s personal computer software was constantly going
thru new versions ... with new features. in the mid-90s, there was some
study that (traditional office oriented) personal computer software had
more features than most people used (only 10 percent of the features
being used by 90+ percent of the people most of the time).
the issue then was what was going to happen to the software houses that
became use to revenue streams from people constantly buying the
latest/new release (somewhat like the old paradigm of people buying
disposable, new cars every year).
"internet" showed up as the new "buzzword" about that time and allowed
new set of "internet" oriented features to continually be advertised
... extended the ongoing revenue stream paradigm related to constant
introduction of new features.
for other topic drift ... i was allowed to play disk engineer
in bldg. 14&15
http://www.garlic.com/~lynn/subtopic.html#disk
one of the things that was going on was that they had several
"testcells" of new equipment being developed ... which had to be
scheduled for stand-along testing with large mainframe (running custom,
stand-alone software monitor).
they had tried bringing up MVS for supporting concurrent testing of
multiple testcells ... however discovered that with just a single
testcell, MVS's MTBF on the order of 15 minutes. so for the fun of it, i
undertook to redo the i/o supervisor ... so the mainframes could be
operating in a operating system environment with concurrent testing of
numerous testcells going on (bullet proof environment that would never
fail). the result was significant improvement in disk engineering
productivity with testing of any testcell could occur at any time (w/o
waiting for the dedicated time allocation).
one (corporate internal only) report mentioning all the work that had to
be done ... and also mentioning the MVS 15 min MTBF issue ... resulted
in taking a huge number of barbs and arrows from the MVS RAS group (not
particularly about it not being true ... but who was I to be allowed to
even refer to such a thing). one folklore was that all of the ill-will
from the MVS RAS group tanked a corporate award for the work.
for even more drift ... a testcell was a heavy steel wire mesh cage with
special combination padlock on each door. this was located inside a
security controlled machine room, inside a security controlled building,
inside a security controlled plant site.
one of the issues was somewhat related to a court case over theft of
condifidential hardware documents by and employee and provided to a disk
clone manufacturer. there was a claim that it represented several
billion dollars i.e. the revenue difference to the clone company to be
able ship a new disk the same day it was announced ... versus at least
six month delay to come up with compatible disk via reverse engineering
after obtaining one via normal sales mechanism.
the court supposedly made some reference effectively that there had to
be security procedures proportional to the claimed value ... otherwise
it could be treated as an "attractive nuisance" ... aka the swimming
pool scenario requiring fence ... otherwise the owner can be held
liable.
Tap and faucet and spellcheckers
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Tap and faucet and spellcheckers
Newsgroups: alt.usage.english,alt.folklore.computers
Date: Sat, 05 Jan 2008 16:06:49
Anne & Lynn Wheeler <lynn@garlic.com> writes:
one of the issues was somewhat related to a court case over theft of
condifidential hardware documents by and employee and provided to a disk
clone manufacturer. there was a claim that it represented several
billion dollars i.e. the revenue difference to the clone company to be
able ship a new disk the same day it was announced ... versus at least
six month delay to come up with compatible disk via reverse engineering
after obtaining one via normal sales mechanism.
the court supposedly made some reference effectively that there had to
be security procedures proportional to the claimed value ... otherwise
it could be treated as an "attractive nuisance" ... aka the swimming
pool scenario requiring fence ... otherwise the owner can be held
liable.
re:
http://www.garlic.com/~lynn/2008.html#25 Tap and faucet and spellcheckers
one of the interesting aspects of this was that the courts seemed to
view, that given a chance, human nature is criminal ... and it is
necessary not to offer the chance; that human nature would be to steal
something worth billions of dollars unless there were sufficient
countermeasures in place (just like kids would jump in swimming pool
unless there was fence around it).
Tap and faucet and spellcheckers
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Tap and faucet and spellcheckers
Newsgroups: alt.usage.english,alt.folklore.computers
Date: Sun, 06 Jan 2008 09:31:00
Anne & Lynn Wheeler <lynn@garlic.com> writes:
one (corporate internal only) report mentioning all the work that had to
be done ... and also mentioning the MVS 15 min MTBF issue ... resulted
in taking a huge number of barbs and arrows from the MVS RAS group (not
particularly about it not being true ... but who was I to be allowed to
even refer to such a thing). one folklore was that all of the ill-will
from the MVS RAS group tanked a corporate award for the work.
re:
http://www.garlic.com/~lynn/2008.html#25 Tap and faucet and spellcheckers
and old email
http://www.garlic.com/~lynn/2007.html#email801015
in this post from 1jan2007
http://www.garlic.com/~lynn/2007.html#2 The Elements of Programming Style
mentioning MVS RAS issues with new disks.
somewhat related posts with regard to results of having offended
some group or another:
http://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer
http://www.garlic.com/~lynn/2007j.html#75 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#83 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#94 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#0 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#4 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#5 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#9 IBM Unionization
As Expected, Ford Falls From 2nd Place in U.S. Sales
Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: As Expected, Ford Falls From 2nd Place in U.S. Sales
Newsgroups: alt.folklore.computers
Date: Sun, 06 Jan 2008 10:29:32
As Expected, Ford Falls From 2nd Place in U.S. Sales
http://www.nytimes.com/2008/01/04/business/04auto.html?ref=automobiles
from above:
Toyota beat Ford in 2007 in United States auto sales, putting it behind
General Motors, industry statistics showed Thursday. Ford had held the
No. 2 spot since 1931, according to the company's historian.
... snip ..
i think the different between Toyota vis-a-vis GM and the recent
overtaking Ford ... is whether or not it is world-wide figures or just
US.
recent postings related to auto imports and competitiveness:
http://www.garlic.com/~lynn/2006x.html#32 Toyota set to lift crown from GM
http://www.garlic.com/~lynn/2007g.html#34 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007g.html#52 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007i.html#13 U.S. Cedes Top Spot in Global IT Competitiveness
http://www.garlic.com/~lynn/2007q.html#4 Horrid thought about Politics, President Bush, and Democrats
still didn't find article that mentions calling for unearned profit
tax ... but some related articles from the period:
http://multinationalmonitor.org/hyper/issues/1984/08/reagan.html
In 1980 the outlook was bleak for U.S. automobile manufacturers. They
had had recent huge profit losses. Employment had fallen by 20
percent. The Chrysler Corporation had just narrowly escaped bankruptcy
by a federal bailout. It was all bad news, but rather than look for
causes within (such as quality control problems and lagging
productivity), the industry blamed Japanese imports. It turned to the
President it had supported in the 1980 election-who had run on a
platform of free market and free trade-and demanded some type of
restraint on imported autos.
In response, Reagan announced in 1981 that the U.S. had reached an
agreement with Japan on a voluntary export restraint limiting Japanese
automobile exports to the U.S. to 1.68 million cars a year.
The result has been a bonanza of auto profits and auto executive
bonuses. Creating an artificial scarcity of Japanese autos has caused
prices of both Japanese imports and U.S. manufactured autos to jump. A
1983 Wharton Econometrics study estimated that in 1981 and 1982, the
prices of Japanese imports increased an average of $920 to $960 per
car. And since 1981, the average price of a U.S. manufactured car has
increased by over 40 percent-twice the rate of increase in the
Consumer Price Index during the same period.
Profits in the U.S. auto industry soared from a loss of $3.8 billion
in 1980 to a gain of $7.7 billion in 1983. Brookings Institute
economist Robert Crandall estimates that "a substantial share of the
explanation must be the price effects of import restraints." And auto
industry executives have cashed in, too: Roger B. Smith, General
Motors chairman, granted himself $1.5 million in cash and stock
bonuses in 1983; Ford's chairman Phillip Caldwell took home $1.4
million.
...
http://www.heritage.org/Research/EnergyandEnvironment/EM74.cfm
From 1981 through 1983 the Japanese were allowed to ship 1.68 million
cars annually to the U.S.; last year the ceiling was 1.85 million. By
restricting the number of imported cars, Washington made it possible
for the auto companies to raise prices without fear of losing business
to less expensive competitors. Wharton Econometrics calculates that
the average price per new car has risen by $2,600 since the market
restrictions were imposed. Brookings Institution economist Robert
Crandall estimates that $400 of this price hike per U.S.-made car was
possible only because quotas reduced competition. With 1984 sales of
nearly 8 million U.S. cars, the quotas took $3.2 billion out of the
pockets of consumers and gave it to the auto industry. Crandall
further estimates that the low supply of imported cars mandated by the
quotas added $1,000 to the pricetag of every Japanese car sold in the
U.S., a total of $1.85 billion in extra consumer costs. The total 1984
bill for U.S. consumers due to auto trade restraints: $5 billion. Some
argue that quotas should be extended because the U.S. auto industry is
still not economically sound. This is a strange argument.
...
pasts posts mentioning there was article raising issue of
unearned profit tax:
http://www.garlic.com/~lynn/2000f.html#41 Reason Japanese cars are assembled in the US (was Re: American bigotry)
http://www.garlic.com/~lynn/2000f.html#43 Reason Japanese cars are assembled in the US (was Re: American bigotry)
http://www.garlic.com/~lynn/2001d.html#43 Economic Factors on Automation
http://www.garlic.com/~lynn/2004b.html#52 The SOB that helped IT jobs move to India is dead!
http://www.garlic.com/~lynn/2004h.html#22 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2005s.html#2 Internet today -- what's left for hobbiests
http://www.garlic.com/~lynn/2006.html#23 auto industry
http://www.garlic.com/~lynn/2006g.html#14 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#17 The Pankian Metaphor
http://www.garlic.com/~lynn/2006g.html#20 The Pankian Metaphor
http://www.garlic.com/~lynn/2006m.html#49 The Pankian Metaphor (redux)
http://www.garlic.com/~lynn/2007j.html#33 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#72 IBM Unionization
http://www.garlic.com/~lynn/2007j.html#88 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#11 IBM Unionization
http://www.garlic.com/~lynn/2007k.html#24 IBM Unionization
Need Help filtering out sporge in comp.arch
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Need Help filtering out sporge in comp.arch
Newsgroups: alt.folklore.computers
Date: Sun, 06 Jan 2008 10:51:24
Charles Richmond <frizzle@tx.rr.com> writes:
Just like "throw away" programs. If you write a quick-and-dirty
program that exceeds 100 lines, be *sure* to throw it away.
Otherwise, someone in the company will find it two years later and
demand that you help them resurrect it. (Alternative, you can just
purge your name and contact information, so whoever finds the source
code is on their own.)
some old email regarding early "csc/vm" system
http://www.garlic.com/~lynn/2006v.html#email731212
http://www.garlic.com/~lynn/2006w.html#email750102
past references to internal, highly modified "csc/vm" that had somehow
leaked out to at&t longlines ... which they propagated to some number of
machines and continued to run it for nearly a decade ... then at&t
national marketing manager tracking me down to see if I could help get
them off that system and on to a current system:
http://www.garlic.com/~lynn/95.html#14 characters
http://www.garlic.com/~lynn/96.html#35 Mainframes & Unix (and TPF)
http://www.garlic.com/~lynn/97.html#15 OSes commerical, history
http://www.garlic.com/~lynn/2000.html#5 IBM XT/370 and AT/370 (was Re: Computer of the century)
http://www.garlic.com/~lynn/2000f.html#60 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2001f.html#3 Oldest program you've written, and still in use?
http://www.garlic.com/~lynn/2002.html#4 Buffer overflow
http://www.garlic.com/~lynn/2002.html#11 The demise of compaq
http://www.garlic.com/~lynn/2002c.html#11 OS Workloads : Interactive etc
http://www.garlic.com/~lynn/2002i.html#32 IBM was: CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002k.html#66 OT (sort-of) - Does it take math skills to do data processing ?
http://www.garlic.com/~lynn/2002p.html#23 Cost of computing in 1958?
http://www.garlic.com/~lynn/2003.html#17 vax6k.openecs.org rebirth
http://www.garlic.com/~lynn/2003d.html#46 unix
http://www.garlic.com/~lynn/2003k.html#4 1950s AT&T/IBM lack of collaboration?
http://www.garlic.com/~lynn/2004e.html#32 The attack of the killer mainframes
http://www.garlic.com/~lynn/2004m.html#58 Shipwrecks
http://www.garlic.com/~lynn/2005p.html#31 z/VM performance
http://www.garlic.com/~lynn/2006b.html#21 IBM 3090/VM Humor
http://www.garlic.com/~lynn/2007g.html#54 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#56 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007u.html#6 Open z/Architecture or Not
http://www.garlic.com/~lynn/2007v.html#15 folklore indeed
hacked TOPS-10 monitors
Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: hacked TOPS-10 monitors
Newsgroups: alt.folklore.computers,comp.sys.unisys
Date: Sun, 06 Jan 2008 11:40:29
"Dave Wade" <g8mqw@yahoo.com> writes:
It depends on what you mean by "fiddle with" and "Monitor". Almost all IBM
sites had some user mods. Many of these would be just extra commands, Others
might be to add support for non-standard hardware, others to tune the
system. VM/370 was largley shipped as source so was frequently modified...
previous post mentioning customers "mods" ... in aggregate
... eventually were larger than the base system
http://www.garlic.com/~lynn/2008.html#14 hacked TOPS-10 monitors
for a little more drift ... only slightly related to this thread:
http://www.garlic.com/~lynn/2008.html#17 Usefulness of bidreictional read/write
in this post referencing getting call about helping get at&t longlines
off a highly modified, ancient csc/vm system
http://www.garlic.com/~lynn/2008.html#29 Need Help filtering out sporge in comp.arch
one of the "local" longlines (additional) modifications was support
for "networked" tape drives. they had extended the device
virtualization for tape drives to work over network (between vm370
machines) ... so applications running on remote vm370 could request
tape mounts and read/write tapes on vm370 systems at other sites.
1975 movie "Three Days of the Condor" tech stuff
Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 1975 movie "Three Days of the Condor" tech stuff
Newsgroups: alt.folklore.computers
Date: Sun, 06 Jan 2008 14:16:03
hancock4 writes:
Someone made a credit card purchase in a store, the cashier phoned in
the verification by voice, reading the credit card info and
transaction over the phone. I forgot about those days. In so many
stores today the credit card verification is integrated in the cash
register itself, others have a separate keypad unit. I haven't seen
an oral transaction in many years.
i had one 20 yrs ago at a dentist ... wasn't especially expensive
... but the excuse was that the "network" was down.
some large merchants would aggregate the electronic transactions and
have one (or very few) interfaces into some acquiring network. most
common seen in lots of stores are machines that do 1-800 calls in real
time into modem bank ... which interfaces into acquiring network.
apparently in this case, the acquiring network had been down for an hr
or so ... and the dentist was being forced into doing "voice" auths.
some number of these are actually automated VRU ... with information
entered via phone keypad.
more recently, i mentioned a situation where stores weren't taking
cards unless they had the old fashion physical "swipe" machines ...
because local (telco) central office had some problem (which lasted a
couple days) we were in the process of moving and having to eat out a
lot ... and also make a lot of new purchases ... so we ran into in
numerous times during the period
http://www.garlic.com/~lynn/2007n.html#84 Poll: oldest computer thing you still use
more topic drift regarding older problem with 1-800 incoming auth
calls
http://www.garlic.com/~lynn/2007o.html#25 LAX IT failure: leaps of faith don't work
for other topic drift ... the long-time old small squat swipe machines
with (numerical) keypad on top ... are perported to be "repackaged"
pc/xt in different form factor ... with flash for harddisk ... running
ms/dos with 1200 baud modem ... at least as far as programming is
concerned. old post mentioning xt/msdos for point-of-sale terminals:
http://www.garlic.com/~lynn/2004e.html#21 A POX on you, Dennis Ritchie!!!
http://www.garlic.com/~lynn/2007r.html#13 What do ATMS and card readers use?
for other topic drift ... misc. posts mentioning compromises of
point-of-sale terminals for skimming transaction information with the
purpose of using the (skimmed transaction) information for fraudulent
transactions:
http://www.garlic.com/~lynn/aadsm22.htm#44 Creativity and security
http://www.garlic.com/~lynn/aadsm22.htm#45 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#46 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm23.htm#2 News and Views - Mozo, Elliptics, eBay + fraud, naïve use of TLS and/or tokens
http://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#32 Chip-and-Pin terminals were replaced by "repairworkers"?
http://www.garlic.com/~lynn/aadsm23.htm#34 Chip-and-Pin terminals were replaced by "repairworkers"?
http://www.garlic.com/~lynn/aadsm25.htm#16 Fraudwatch - Chip&PIN one-sided story, banks and deception and liability shifts
http://www.garlic.com/~lynn/aadsm27.htm#32 The bank fraud blame game
http://www.garlic.com/~lynn/2005g.html#41 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2006u.html#40 New attacks on the financial PIN processing
http://www.garlic.com/~lynn/2006x.html#14 IBM ATM machines
http://www.garlic.com/~lynn/2007.html#5 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007.html#6 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007b.html#13 special characters in passwords
http://www.garlic.com/~lynn/2007r.html#72 Translation of IBM Basic Assembler to C?
and even more drift ... a couple news articles from the past couple days:
Citibank limits ATM cash withdrawals in NYC (atm fraud)
http://www.atmmarketplace.com/article.php?id=9544&na=1
UK Bank Faces Chip-and-PIN Fraud Lawsuit
http://www.epaynews.com/index.cgi?survey=&ref=browse&f=view&id=1199470277837043222&block=
1975 movie "Three Days of the Condor" tech stuff
Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 1975 movie "Three Days of the Condor" tech stuff
Newsgroups: alt.folklore.computers
Date: Sun, 06 Jan 2008 14:21:54
"Charlie Gibbs" <cgibbs@kltpzyxm.invalid> writes:
In any event, the only difference between BCD and EBCDIC keypunches
was the characters printed on the keytops and generated by the print
unit. The combination of rows punched by a key in any given position
on the keyboard remained the same regardless of model. I made good
use of this knowledge in shops with a mix of BCD and EBCDIC punches;
you can touch-type the same code on any punch, which allowed me to
bypass many lineups.
in fact, it was possible to "multi-punch" on the machines ... even
purely (ebcdic) "hex" codes w/o any corresponding character or key (on
any machine, 026, 029, etc). misc. past posts mentioning "patching"
executable 12-2-9/TXT decks by combination of card reproduction and
multi-punching the patch into the new card:
http://www.garlic.com/~lynn/93.html#17 unit record & other controllers
http://www.garlic.com/~lynn/95.html#4 1401 overlap instructions
http://www.garlic.com/~lynn/2000b.html#44 20th March 2000
http://www.garlic.com/~lynn/2000f.html#75 Florida is in a 30 year flashback!
http://www.garlic.com/~lynn/2001.html#8 finding object decks with multiple entry points
http://www.garlic.com/~lynn/2001.html#14 IBM Model Numbers (was: First video terminal?)
http://www.garlic.com/~lynn/2001.html#60 Text (was: Review of Steve McConnell's AFTER THE GOLD RUSH)
http://www.garlic.com/~lynn/2001b.html#26 HELP
http://www.garlic.com/~lynn/2001b.html#27 HELP
http://www.garlic.com/~lynn/2001k.html#27 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2001k.html#28 Is anybody out there still writting BAL 370.
http://www.garlic.com/~lynn/2001m.html#45 Commenting style (was: Call for folklore)
http://www.garlic.com/~lynn/2002h.html#1 DISK PL/I Program
http://www.garlic.com/~lynn/2002k.html#63 OT (sort-of) - Does it take math skills to do data processing ?
http://www.garlic.com/~lynn/2004h.html#17 Google loves "e"
http://www.garlic.com/~lynn/2004p.html#24 Systems software versus applications software definitions
http://www.garlic.com/~lynn/2005c.html#54 12-2-9 REP & 47F0
http://www.garlic.com/~lynn/2005t.html#47 What is written on the keys of an ICL Hand Card Punch?
http://www.garlic.com/~lynn/2006b.html#1 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#17 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006g.html#43 Binder REP Cards (Was: What's the linkage editor really wants?)
http://www.garlic.com/~lynn/2006g.html#58 REP cards
http://www.garlic.com/~lynn/2006l.html#64 Large Computer Rescue
http://www.garlic.com/~lynn/2006n.html#1 The System/360 Model 20 Wasn't As Bad As All That
http://www.garlic.com/~lynn/2006n.html#11 Not Your Dad's Mainframe: Little Iron
http://www.garlic.com/~lynn/2006t.html#30 Why these original FORTRAN quirks?
http://www.garlic.com/~lynn/2007d.html#51 IBM S/360 series operating systems history
http://www.garlic.com/~lynn/2007f.html#78 What happened to the Teletype Corporation?
http://www.garlic.com/~lynn/2007o.html#44 64 gig memory
http://www.garlic.com/~lynn/2007q.html#69 IBM System/3 & 3277-1
http://www.garlic.com/~lynn/2007q.html#70 IBM System/3 & 3277-1
http://www.garlic.com/~lynn/2007s.html#8 Anybody remember Keypunch cards?
JCL parms
Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: JCL parms
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Sun, 06 Jan 2008 14:38:35
shmuel+ibm-main@PATRIOT.NET (Shmuel Metz , Seymour J.) writes:
No. The original design of OS/360 was that all programs were
subroutines. A program written to be called as a jobstep task could
also be called via LINK or ATTACH from another program. It was never
designed for programs to assume that they were jobstep tasks, although
IBM may have written code[1] that assumed that.
some number of univ. developed their own student job "monitors"
(predating availability of watfor).
we had 709 running fortran monitor for student jobs ... runnin