But AFAIK that hasn't been eliminated (though businesses would like for it
to be). That law (stemming from Enron et al.) does things like stiffen
requirements for financial reporting of corporations (and hold
executives liable for fraudulent reports)..

in the financial area there was new qualitative section of basel II
... but that pretty much eliminated before basel II was adopted.

i gave a talk at european finance conference a couple yrs ago that SOX
couldn't prevent/eliminate the ENRON type stuff ... since the criminal
activity was already criminal ... that about the only part of SOX that
was really new was the section at the end on informants.

2741s, was Even worse than UNIX

johnl@iecc.com (John L) writes:
The only problem with 2741s was that they were extremely unreliable.
The Selectric mechanism wasn't intended to be driven at full speed
page after page. In the terminal room at Princeton I used, I don't
ever remember all of the dozen or so 2741s working at the same time.
KSR 33's, on the other hand, just kept on working.

depends on the duty cycle they were manufactured for ... 1052-7
operator's consoles used essentially same golf ball mechanism ... but
were manufactured for significantly heavier duty cycle. in fact most of
the 1052 models were built for significantly heavier duty than 2741s.

i had 2741s for personal use (one at office and one at home for several
yrs w/o problems).

"David Cressey" <cressey73@verizon.net> writes:
I know practically nothing of CDC culture, but quite a bit about DEC
culture, going way back. My impression of CDC culture, gleaned indirectly
from what Niklaus Wirth had to say about the CDCmachines, is that CDC
culture discovered interactive development later than DEC culture did. I'm
just about certain that IBM culture discovered interactive development later
than DEC culture did. This is somewhat related to the topic at hand.

I've often commented that it wasn't that IBM culture didn't have
interactive development ... which was compareable to features/size of
most other vendors (that might be considered interactive) ... it was
that in the 60s, 70s & much of the 80s, the batch market size
dwarfed the interactive.

in afc ng ... i've often mentioned that the number of vm/43xx customer
installs were larger than vax/vms installs ... in part because some
number of large customers would order then in blocks of 100s at a time
(i don't believer there were ever any single vax/vms orders for 1000
machines ... until possibly you got to microvax). misc. old email
discussing 43xx activity
http://www.garlic.com/~lynn/lhwemail.html#43xx

one of my hobbies was building and supporting highly modified custom
operating system for internal distribution. i've periodically joked that
the number of customer batch systems were much larger than the number of
customer vm systems. the number of customer vm systems were much larger
than the total number of internal vm systems. the total number of
internal vm systems were much larger than the peak number of internal vm
systems that i provided distribution and support for. however, that peak
number (that i directly built, distributed, etc) was still as large as
the total number of multics systems that ever existed. this comparison
was somewhat because the vm stuff had started on the 4th flr of 545 tech
sq ... and the multics stuff was on the 5th flr ... misc. past posts
about science center and 545 tech sq
http://www.garlic.com/~lynn/subtopic.html#545tech

John W. Backus, 82, Fortran developer, dies

Charlton Wilbur <cwilbur@chromatico.net> writes:
No, I'm assuming that virtual payments mean I will need to instruct
some entity to transfer money from one account to another. Some
identifying information will need to be made public, or how will I
tell the money where to go?

Either I need to provide my account number to the person I want to
give money to so that they can withdraw the money, or the person I
want to give money to needs to give me his or her account number so
that I can send the money. Alternately, we could both give our
account numbers to a trusted third party. But you can't get around
needing to give out the account number or other personally identifying
information.

the issue isn't so much that you divulge the account number ... it is
that the account number (and other "static" information) is sufficient
to authenticate and perform a transactions .... making the
infrastructure vulnerable to replay attacks.

note that just having unique per transaction information ... aka or
"dynamic data" ... while it may be countermeasure to replay attacks
... it doesn't necessarily mean that it isn't vulnerable to things like
man-in-the-middle attacks ... it depends on details of the
implemenation. for example, in the posts about yes cards
... "dynamic data" is suggested as countermeasure to the yes
cardreplay attack vulnerability. However, the "dynamic
data" implementation may still be vulnerable to man-in-the-middle
attackshttp://www.garlic.com/~lynn/subintegrity.html#yescard

in posts about the "naked transaction" metaphor ... the countermeasure
integrates the authentication and integrity operations with the actual
transaction ... in effect "armoring" the transaction ... as
countermeasure to wide range of attacks (including replay
attacks and man-in-the-middle attacks)
http://www.garlic.com/~lynn/subintegrity.html#payments

... now, normally, multi-factor authentication is assumed to be more
secure because the different factors are subject to different threats
and exploits ... for example PINs (i.e. something you know) are
considered countermeasure to lost/stolen cards (i.e. something you
have) ... modulo writing the PIN on the card.

dynamic data built into the card ... isn't considered multi-factor
authentication ... i.e. providing different countermeasures
to a single threat ... like lost/stolen card. dynamic data built into
the card is more secure form of a single mode of authentication
... providing countermeasure to replay attacks ... but
can still vulnerable to single threat from a lost/stolen card.

timcaffrey@aol.com (Tim McCaffrey) writes:
Of course, with IDE drives looking to move to 4K sectors, the side-effect of a
single sector failure for databases can be all that more annoying.

all other things being equal, any specific 4k record might have 8times
the probability of failing as 512 byte record (being 8times as large
... also comes up in things like yield when manufacturing large sized
chips).

however, the better FEC may reduce the overall number of record hard
failures that a disk might have i.e. improves the overall reliability
of a drive while increasing the probability of any specific record
failure by something less than 8times. raid has become much more
common place as countermeasure to both drive and record
failures.

we were working with a company called cyclotomics that specialized in
reed-solomon error correcting codes ... for some of our high-speed
links. cyclotomics had also been active in FEC for cdrom standard (with
2k byte blocks) ... and were eventually bought by Kodak.

some of this was because some of the links where high-speed satellite
links (i.e. on a link getting 10**-9 bit-error-rate, 15/16ths
reed-solomon FEC could provide the effective equivalent of 10**-15
bit-error-rate ... i.e. about six orders of magnitude improvement). we
also had somebody that was considered one of the five best satellite
RF engineers in the world and who also happened to be a graduate
student of reed's at caltech. but then ... he would also say that his
favorite instructor at mit in his undergraduate days had been my
wife's father.

in any case, i was trying to really push the envolope (at the time)
... trying to do an interface that would sustain up to 3mbytes/sec
... do reed-solomon FEC and do crypto (along with being able to handle
changing crypto key on every packet ... i.e. stepup from raw link
encryptor).

Even worse than UNIX

"David Wade" <g8mqw@yahoo.com> writes:
Linux already will do record orientated I/O thats why C has two I/O
paradigms.Looking for an <LF> character seems pretty trivial compared to the
overhead of MVS variable length i/o which has logical ecord sizes on the
front of each record. Even worse if you are doing variable block size on
tape where you have the block size in the front as well. Also note that MVS
disks (usually known as DASD) can have each track formatted with a different
block size. In practice a given file will usually have the same block size
for all blocks, so for cards sized records they will often be blocked 800 or
8000, whereas for a file with longer records bigger blocks will be used.
Thats why you need tables like this to "allocate" a file:-

MTS *FS tape format?

"David Wade" <g8mqw@yahoo.com> writes:
I only ever used MTS on the pre 3270 (I forget the model) displays. I seem
to recall that the screen was buffered in controller memory. How I wish I
had kept the manuals from then...

when i was an undergraduate ... i was involved in doing something
similar ... but building a "better" terminal controller out of
interdata/3 (which evolved into combination of interdata/4 and
interdata/3s). there was some subsequent article about getting blameed
for contributing to the clone controller business .... lots of past
posts
http://www.garlic.com/~lynn/subtopic.html#360pcm

later interdata was bought and the boxes marketed under the perkin/elmer
brand. within the past decade ... i even ran into installation with
still operating perkin/elmer box handling a lot of traffic in a large
transaction processing datacenter.

paul c <toledobythesea@oohay.ac> writes:
also, not sure if you could even buy them then or around 1965 when the
360's made their splash, the price was nominal to satisfy accountants,
either or both corporate or governmental and leasing was the only way
to acquire. the even bigger money was in maintenance fees and buyer
lock-in.

much smaller world then. around 1990, i asked some knowledgeable
hardware types how many mainframes there were in the world and how
many were sold per year, of 3033 class (speed of what was called a
"couple of mips") and the general concensus seemed to be several
thousand, with a big sales year for Hitachi, Amdahl and IBM consisting
of several hundred boxes sold. i know some 4341/4381's approached
that mip rating, but find it hard to believe that there were many
customers who ordered hundreds of them.

Multiply those numbers by a few dozen or a hundred real programmers
for each cpu and it's not hard to see why brain-washed oldtimers wax
nostalgic or why there is so much commercial chaos now, with hundreds
of thousands of accomplished programmers who have an equal right to
believe they have seen the truth.

both vax/vms and 43xx machines appeared to drop below threshhold and
started trend towards department machines. by the mid-80s and 4381
time-frame ... workstations and larger PCs were started to take over
that market segment.

43xx ... aka 4331 (follow-on to 135/138) and 4341 (follow-on to
145/148) shipped more in that mid-range market than DEC. both 43xx
follow-on and dec vax/vms show the effect of workstations and large
PCs starting to take over that mid-range market in the mid-80s.

includes discussions working with the disk division on moving various
disk design and development tools to clusters of 43xx machines
... that resided in various locations outside the datacenter (and off
of the large mainframes that required extensive faciilties, cooling,
and space requirements in large datacenters). part of the discussion
was that there was never going to be any way that they were going to
be able to cost justify and/or provide physical facilities ... for the
amount of processing that was going to be needed (assuming the
high-end mainframes).

"David Cressey" <cressey73@verizon.net> writes:
Fair enough. IBM culture was big enough, at the time, so it could
accommodate a large number of internal subcultures. The part of IBM culture
that was visible to me was definitely not into interactive development.

Even though they had interactive terminals, on line editing, etc. etc.
compiling a source program was a batch job. And that affected the workflow.

no, the comment was the "customer" market size for interactive
computing was compareable to other vendor's interactive computing
market size.

that is separate from the comment that the internal interactive use
was extensive.

however, the observation was that the batch market size was so much
larger (than either) ... that it skewed a lot of perception.

there were several internal battles over feature/function of 3270
terminals ... with product managers frequently claiming the 3270 major
market was for "data entry" (related to batch environments) as opposed
to interactive computing (in part ... again ... because the "data
entry" market size was so much larger than the interactive computing
market size).

for some topic drift ... part of it was resolved with the introduction
of ibm/pc. i've frequently commented that a big part of the uptake for
ibm/pc was that there was large business volume in 3270 desktop
terminals. ibm/pc cost about the same as 3270 terminal ... and it
could emulate a 3270 terminal with some local application software
capability ... in a single desktop footprint. it would be an easy
business justification no-brainer to switch the 3270 terminal
allocated budget from real 3270s to ibm/pc. lots of past posts related
to terminal emulation and market uptake for ibm/pc
http://www.garlic.com/~lynn/subnetwork.html#emulation

on a specially modified 360/40 with virtual memory hardware ... and
"CMS" (cambridge monitor system) for interactive computing. When
standard 360/67 with virtual memory became available, cp40 was ported
and renamed cp67. later with the introduction of virtual memory
standard on all 370s, cp67 morphed into vm370 (and cms was renamed to
the conversational monitor system).

the really big volumes in vm370 started to appear with 4341s ... with
the explosion in the mid-range market segment (also seen by DEC with
vax/vms). subsequently in the mid-80s, this market segment started
moving to workstations and large PCs.

Anne & Lynn Wheeler <lynn@garlic.com> writes:
on a specially modified 360/40 with virtual memory hardware ... and
"CMS" (cambridge monitor system) for interactive computing. When
standard 360/67 with virtual memory became available, cp40 was ported
and renamed cp67. later with the introduction of virtual memory standard
on all 370s, cp67 morphed into vm370 (and cms was renamed to the
conversational monitor system).

the really big volumes in vm370 started to appear with 4341s ... with
the explosion in the mid-range market segment (also seen by DEC with
vax/vms). subsequently in the mid-80s, this market segment started
moving to workstations and large PCs.

for other topic drift ... the original relational/sql implementation was
done at SJR on vm370 (in the late 70s, backus office was about six doors
down from mine, and codd's office was upstairs from mine). lots
of past references to system/r
http://www.garlic.com/~lynn/submain.html#systemr

then there was system/r technology transfer from SJR to Endicott for
SQL/DS (i.e. vm370, vs/e, 4341s, etc).

claimed to have handled majority of the technology transfer from
Endicott back to STL for DB2 (even tho SJR and STL were only about 10
miles apart). This was all "mainframe" and mostly implemented in PLS.
(DB2 on the corporation's mainframe "batch" platform, MVS)

jmfbahciv writes:
And the Computer Center has a Cray for you. It has never failed
before when you've used it for your long runtime calculations.
Are you, the researcher, going to spend your valuable time
writing checkpoint software or are you going to work on the
numerical analysis code?

I know what the chocie will be...and it ain't checkpointing
for a system that has never been known to crash.

in much of the 70s, SJR ran MVT 370/195 service ... that a lot of
organizations used, however, backlog & turn around could be measured in
months.

one of the things i've mentioned before is when bldg. 15 (disk product
test lab) got 3033 ... we were able to move air bearing simulation
application (part of designing floating thin-film heads) move the 195
across the street to the 3033 ... getting significantly better
turn-around ... a couple recent posts
http://www.garlic.com/~lynn/2007f.html#46 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007i.html#83 Disc Drives

the 3033 had about half the thruput of the peak 195 thruput ... however
a 3033 with effectively zero percent utilized would have much better
turn-around than waiting weeks for 195 turn around.

palo alto science center also was getting lengthy turn-arounds on some
of their numerical intensive workload being run by sjr's 370/195. they
had a 370/145 running vm (they had done both the morph from cms\apl to
apl\cms as well as the apl microcode assist on the machine) ... which
had about 1/30th the thruput of 195. The 370/195 batch workload ran
24hrs/day 7day/week. Palo Alto's vm interactive service was primarily
first shift and the machine was mostly unloaded 2nd, 3rd and
weekends. Palo Alto did some checkpoint support and started the
application on their 145 in the background ... so it got whatever
spare cycles were available 1st shift and much of the off-shift
processing cycles. While it might take the application several weeks
to complete on the 145 ... that was better turn-around than they were
getting from the sjr 195.

"David Cressey" <cressey73@verizon.net> writes:
You are absolutely right. I can back that up from my own experience. At
about the 1969 time frame, I had been using interactive timesharing systems
for a while, and I knew how to use the debugger and the text editor
amazingly well. But my ability to design a piece of software that was
logically correct (barring minor errors) at the outset was, in retrospect,
less than it might otherwise have been.

Between 1969 and 1980, due to a series of job changes and outlook changes,
I migrated from assembler to Pascal. Pascal was the first language that I
learned thoroughly before writing any programs. And, in the Pascal learning
materials, there was a great deal about designing a program correctly.

Wirth had the attitude that there was no reason why a carefully written
program shouldn't compile on the first try. I never got as rigid as that.
But Pascal ended up being the main reason I never learned the VAX debugger.
The VAX debugger was, by all accounts, much more powerful than the earlier
more primitive tools I had used (DDT for example).

however, i've mentioned also working on a "relational" DBMS
implementation for the Los Gatos VLSI tool group (that had some
participation from some people in STL). This was relational in the
sense that all the relations were directly instantiated ... rather
than a data dictionary that applied to a uniform table structure. It
shared characteristics with System/R that the "relations" were
abstracted with indexes under the covers (and not exposed as part of
the data).

paul c <toledobythesea@oohay.ac> writes:
Nit: I think this should have said "typical" IBM culture. I once
worked in an atypical IBM shop where, for example, very few
programmers knew any JCL, that included assembler programmers. Nearly
everybody used TSO and TSOTEST exclusively for compiles and
assemblies, so-called "link-edits" and debugging. There was no
waiting for batch jobs to start. Typical IBM installations usually
forbade this for cost reasons but a few bought enough hardware to
allow it. I found it just as productive as using the early Borland
"Turbo" integrated environments on a dedicated PC. Very few people
needed to understand how to write tso "clist" scripts, just as very
few Borland customers needed to modify the standard "workflow". One
could expect several thousand lines to assemble and link with other
code in as little as ten seconds and usually compiles too. One
typically was dealing with several hundred thousand lines in any given
component, but things were arranged so that usually only a handful of
modules needed to re-compiled.

for much of the seventies, SJR ran batch MVT service on 370/195. There
was some numerical intensive "JOBs" that could have several week turn
around. recent post with reference to palo alto science center moving
one of their jobs to background on their vm/145 (still talking several
weeks to complete ... but turn around was shorter/less than what they
were getting on the 195 ... peak performance of 195 was about 30times
that of 145):
http://www.garlic.com/~lynn/2007j.html#13 Interrupts

mentions much later when the corporation had decided to transition to
some number of COTS VLSI tools ... as part of that transition they were
providing some of the VLSI tool vendors copies of some of the internal
applications.

by that time, vs/pascal was supported for both mainframe operation and
rs/6000 (aix) operation. however, as part of the COTS tools transition,
various of internal tools had to also run on other vendor workstations.
I had opportunity to port one 60,000 line pascal application to other
platforms ... however, it seemed like these other implementations had
never gotten much past the student programming application stage (and
never dealt with a 60,000 line application).

"David Cressey" <cressey73@verizon.net> writes:
Fair enough. IBM culture was big enough, at the time, so it could
accommodate a large number of internal subcultures. The part of IBM culture
that was visible to me was definitely not into interactive development.

Even though they had interactive terminals, on line editing, etc. etc.
compiling a source program was a batch job. And that affected the workflow.

one of the things you started to see with cp/cms in the 60s was the
appearance of a number of personal computing applications (similar to
various of the things that you would later see on PCs. in the 80s).

to offer commercial time-sharing services. they transitioned to 370
machines when virtual memory became readily available on all 370
machines. they were also joined by tymshare offering commercial
vm370-based time-sharing services. lots of post posts mentioning
cp/cms and vm/cms based time-sharing services
http://www.garlic.com/~lynn/submain.html#timeshare

one of the things that started to show up with interactive computing was
games. in the 70s, tymshare had ported the adventure dec fortran source
to vm/cms and i obtained a copy for internal corporate distribution. at
one point, the executives in STL complained that they thot nearly
everybody was spending their days playing adventure on vm/cms (instead
of doing dbms development). recent post mentioning adventure:
http://www.garlic.com/~lynn/2007g.html#0 10 worst PCs

starting out with most of the application written in cms\apl on cp67 and
then transitioning to vm370 and apl\cms. Sometime in the early to mid
70s, sales couldn't even submit a 370 order w/o it having first being
processed by a HONE "configurator".

To continue the theme that there were a lot of cms personal computing
applications ... the type of things you started seeing moving to PCs in
the 80s ... there were a lot of APL-based applications doing "what-if"
type things ... that you later see implemented with PC-based
spreadsheets.

An early one was when the cambridge science center first ported apl\360
to cms for cms\apl. The apl\360 service offerings typically limited
workspace sizes to 16kbytes (or in some cases 32k). With cms\apl, the
size of the APL workspace could be nearly as large as the virtual
address space. This opened up a lot of "what-if" applications using
real-world data. Early on, we found corporate business planners shipping
tapes to Cambridge with the most sensitive customer and corporate
business data ... and using the science center cms\apl facilities to run
"what-if" business planning scenarios. a couple recent references
mentioning business planners in corporate hdqtrs using the cambridge
cms\apl facilities:
http://www.garlic.com/~lynn/2007i.html#20 Does anyone know of a documented case of VM being penetrated by hackers?
http://www.garlic.com/~lynn/2007i.html#77 Sizing CPU

John W. Backus, 82, Fortran developer, dies

Greg Menke <gdmnews@toadmail.com> writes:
There is a very big difference between interrupting a cpu and
arbitrating writing a cache-line back to ram, the latter being what
multiprocessors generally do. When there is no contention between
cache-lines, then there is no delay.

maybe there is some reference about cross-cache chatter ... which
doesn't show up with processor interrupts visible to software.

the 370 SMPs ... would slow down the processor machine cycle by ten
percent ... to allow for cross-cache chatter ... and any actual
cross-cache chatter (needing handling) would slow the processors down
even further. basically, anytime that cache-line was obtained for
alternation (whether store-thru cache implementation or a store-into
cache implementation) ... there would have to be cross-cache invalidates
to clear cache-line from any other processor.

the cross-cache overhead tripled going from two-processor smp
configuration (one other cache to listen for) to four-processor smp
(three other caches to listen for). in the 3084 time-frame, major
operating systems had some amount of kernel storage re-organization to
force kernel storage to be aligned on cache-line boundaries and
allocated in multiples of cache-line units. this change supposedly
improved overall avg. system thruput by 5-6percent (just eliminating
possible kernel storage cache-line trashing, aka two different kernel
storage areas overlapping in the same cache-line).

there have been some number of optimizations to eliminate cross-cache
chatter overhead and allow better processor scaling. an early one was
snoopy caches ... where all caches would watch all memory bus operations
... whenever one cache saw a memory bus operation from some other cache
... that involved a cache-line that it had loaded, it would invalidate
it (aka sort of an implicit cross-cache signal).

note this is a cache function ... involving copies of the same data in
different physical caches ... not a processor function. when you have
multiple processors sharing the same physical cache ... the issue
doesn't come up.

jmfbahciv writes:
My experience with unions is they order you to work less and less
and less. My Dad got severely spoken to (this was a Teamster
union) for picking up a broom and sweeping his work area.
Only the broom union members were allowed to touch a broom.

I was brought in during summer break as a full-time employee to help
setup BCS (boeing computer services) operation (earlier they had talked
me into giving a 40hr dataprocessing class during spring break to some
of the BCS technical staff).

This was shortly after BCS had been formed ... it was sort of to move
all dataprocessing into a separate business unit and change it from
expense category and give it profit/loss responsibility (even if it was
mostly internal corporate fund transfers ... however, it was also
allowed to perform dataprocessing and consulting outside the company).

I ran into a similar situation when I suggested that I was going to
install a pencil sharpner on the wall near my desk (this involved
driving screws into the wall).

he left and joined BCS consulting. I dropped by later and he was
explaining how they had a contract with USPS to do the financial
modeling justifying postal stamp increase (from 8 to 10?) ... as I've
often repeated before ... back then, APL was commoningly used for a lot
of things that are currently done with spreadsheets.

krw <krw@att.bizzzz> writes:
If the company goes under because of the retirement and medical plans
the employee isn't helped either.

what i was told in the steel industry case ... was that companies were
declaring bankruptcy when they showed that half the cost of a ton of
steel was retirement benefits.

the problem seems to drift into the theme of the comptroller general
claiming that nobody is able anymore of doing simple middle school
arithmatic ... i.e. the benefits were not fully funded ... but were
being paid out of the current operating revenue. The problem extended
to executives, unions, gov. officials, and employees. Everybody was
taking all the money they could at the moment ... and tomorrow was
somebody else's problem.

Supposedly when the company went into the red in 1992 ... they also
took a charge-off to move to fully funded retirement program
(i.e. since they were already in the red, going further into the red
didn't make that much difference). However, a lot of corporations
never have bothered to do that ... assuming that it in the worst case,
it can be left up to the taxpayers to cover the difference at some
point in the future. An issue ... also raised by the comptroller
general, is that it assumes the number of taxpayers continue to
significantly outnumber the recipients ... there is also a matter of
simple middle school arithmatic involved here too.

maybe there is requirement to return to using APL for doing financial
modeling ... of course it still doesn't really make up for the lack of
middle school arithmatic skills ... since it would take some
understanding to even write the APL programs.

other folklore ... i've seen lots of references ... but haven't
actually read the statutes ... claims that in the mid-90s congress
passed some legislation that changed some accounting rules, allowing
companies to claim funded retirement plans as assets. it doesn't make
a whole lot of practical difference to the running of the company
... except for possibly the size of executive bonuses that are tied to
such numbers. however, there is the claim that since it is claimed as
an asset, if a company were to declare bankruptcy ... assets are
available for paying off creditors (possibly even including funded
retirement benefits).

for other drift ... in the mid-80s (20+ yrs ago), I spent a summer
touring around europe doing market support, giving talks and teaching
classes (I wasn't paying close attention to geography and one sequence
went boeblingen, stockholm, zurich over 3week period when it would
have been much easier to do boeblingen, zurich, stockholm). At one
location where i was teaching a 40hr, one week class, i was in the
habit of coming in an hr or two early and staying a couple hrs in the
evening to login back to the states and do email and some number of
other things.

i then asked if i could come in over the weekend to get some work
done. i was told that i was creating a significant bureaucratic paper
work problem for the local management. It seems that the company
benefits had included vacation time that was one week more than the
gov. mandated. As a result, the employees had come to think of
themselves as priviledge compared to their fellow countrymen.

Recently, the gov. had just increased the mandated vaction time by one
week and many employees believed that the company should then also
increase its vacation time by a week (to preserve the one week more
than gov. mandated for all other workers in the country). Since the
company hadn't done that, the unions were taking various work
actions. This included the guard union observing that I was spending
more than 8hrs/day in the bldg ... and filing various forms with the
gov. about work violations (which management had to respond to
... also in writing with the appropriate forms). If I were to (also)
come in on the weekend, it would significantly increase the
gov. paperwork forms that they would have to file (in response to the
anticipated forms that would be filed by the guard union).

John W. Backus, 82, Fortran developer, dies

Greg Menke <gdmnews@toadmail.com> writes:
Microsoft software runs on single or multiple cpu systems. Win9x and
earlier won't take advantage of multiple processors, IIRC extra
processors are idle. You seem preoccupied with syncronization methods
but few minutes using google will show you that this is a well-solved
problem. Yes, its true that if there are no measures taken to serialize
access to shared resources that the processors will step on each other's
work- but its also true that serializing them is easily done. Google
compare and swap insructions.

the mnemonic CAS comes from charlie's initials ... which then required
coming up with the phrase compare and swap, to go with
charlie's initials.

as previously mentioned when attempting to first get compare&swap into
370 architecture ... it was rejected based on various assertions that
test&set instruction was sufficient for handling multiprocessor
syncronizations. the challenge given was that in order to justify
compare&swap instruction inclusion in 370 architecture
... there had to be uses that weren't multiprocessor specific; thus
were born the descriptions of using compare&swap
instruction in multithreaded/multiprogramming applications ... whether
or not running in a multiprocessor environment. a few recent post
references:
http://www.garlic.com/~lynn/2007i.html#31 Latest Principles of Operation
http://www.garlic.com/~lynn/2007i.html#49 John W. Backus, 82, Fortran developer, dies

above post in this thread also includes URL pointer to the description
of compare&swap uses in the current principles of operation
(some 35yrs later)

paul c <toledobythesea@oohay.ac> writes:
I had the attitude that "batch" was a synonym for "bait and
switch". Marketing material would show people getting instant answers
to various questions but once the new machinery was installed,
customers would complain that there weren't hours in the day to get
all their work done. Service rep's would then advise that productivity
would improve with better utilization, eg., keeping the expensive cpu
100% busy, eliminate interactive work, make people schedule their
machine time in advance and jostle for position in the queue. Soon a
scheduling software industry appeared. Accountants saw the
opportunity to record and ration machine time. Even when the TRS80's,
Apples and PC's appeared, nostalgia for those ways didn't evaporate,
maybe even grew. Human nature to preserve the old ways and
idiosyncrasies of most fields. It will probably take decades for SQL
to go away.

weren't nearly as sophisticated or powerful as the tools used by the
tools group in the los gatos VLSI lab for their DBMS development.
Somewhat as a result, the tools group also had somewhat more
experience and sophistication in doing a DBMS language for their
implementation.

for topic other drift ... a reference about early on, somebody doing some
cms application re-implementation for the TRS80
http://www.garlic.com/~lynn/2007.html#1 "The Elements of Programming Style"

in 1969 (aka G, M, and L, are the initials of the three people
responsible ... they then had to come up with the phrase "generalized
mark-up language" to correspond with their initials). It then took
quite awhile for GML to evolve thru SGML, HTML, XML, etc.

GML language support had been added to the CMS document formating
application "SCRIPT". Archeological reference to HTML evolving from
the "waterloo" version of CMS script command in use at CERN:
http://infomesh.net/html/history/early//

objective was in 3mths elapsed time working half-time ... have something
with ten times the function and ten times the performance of the
existing tool (that had been implemented in assembler). it included some
amount of code that searched the dump for specific kinds of failure
signatures.

in the morph from cp67 to vm370, i suggested that each of the svc0
instructions be followed by unique identification codes to facilitate
identifying the failure cause. The 1st response to the suggestion was
that you can't embed data in an instruction stream ... since there would
be an execution failure on return to the svc0 instrucation. Pause ...
there was never going to be a return to the svc0 instruction ... since
the kernel was going to dump and fail.

Even worse than UNIX

Frank McCoy <mccoyf@millcomm.com> writes:
Ten times the function and performance?
Usually I've been quite satisfied to get three to four times the
performance; while management usually expected only 1.5 to 2 times ...
Thus making me look pretty good when the program got finished.

it was somewhat a given that it might be possible to do ten times the
function ... with appropriate higher-level language ... as compared to
assembler code implementation ... the trick was also getting ten times
the performance out of the interpreted REXX implementation compared to
the assembler implementation ... part of the demonstration was to
support a claim that freed from having to deal with low-level
assembler gorp, it allowed a person to better concentrate on solving
the problem ... which also included being able to recognize new ways
of optimized implementation.

early on in working on cp67 as undergraduate ... i had been known to
achieve 100 times performance improvement for some kernel pathlengths.
but over the yrs ... as more and more things were optimized ... it
became harder and harder to find additional things where it was
possible to obtain 100 times performance improvement.

Frank McCoy <mccoyf@millcomm.com> writes:
Ten times the function and performance?
Usually I've been quite satisfied to get three to four times the
performance; while management usually expected only 1.5 to 2 times ...
Thus making me look pretty good when the program got finished.

for totally different subject ... about a decade ago, we had been
asked to look at ROUTES ... one of the major applications in airline
res system ... and given a list of ten things that were then currently
impossible to do.

looking at it, completely changed the paradigm of how ROUTES went
about being implemented ... and were also able to then implement all
ten impossible things. As part of the complete paradigm change
... also speeded up things by a factor of 100 times.

However, also as part of the paradigm change ... three separate
person/human transactions were collapsed into a single operation
... and that single operation did quite a bit additional work
(compared to what had happened in all three of the previous separate
operations) ... so it actually netted out to have only ten times the
"transaction" rate as the prior implementation (although the
definition of what was now a transaction had dramatically changed).

note initially ... it was only about 20 times faster ... but careful
study of the cache structure and re-arranging a lot of program data
structures to better match the machine's cache operation ... got another
five times improvement (5*20 ... netted 100 times).

Andrew Swallow <am.swallow@btopenworld.com> writes:
I first programmed a double CPU minicomputer in 1979. Ten years later
microprocessors had allowed the electronic engineers to get 6 CPUs on
the same shelf. Each CPU had its own software. The software to
control the radios was definitely different from the software to run
the MMI. However they all had to work together to get what we now call
email out.

most microprogrammed 360s & 370s had physical separate boxes for
different microprocessors ... when there were different
microprocessors ... i.e. processors, channels, controllers, devices
... example is 370/158 with microprocessor ... but two different
microcode loads ... one for 370 execution and one for integrated
channel operation. i've mentioned before that transition to 303x
... involved repackaging a 158 microprocessor engine (this is not so
much micro as in small but micro as in microcode) as (dedicated)
"channel director" (with only the integrated channel microcode
load). Then a 3031 become two 370/158 microprocessors ... one with
just the 370 microcode load and the "channel director" with just the
integrated channel microcode load.

however, in the early 70s, Boeblingen got into a little trouble (with
corporate) doing something different for the 370/115 and 370/125. They
created a 9-position shared memory bus (i.e. positions for up to nine
processors). A 370/115 was an microengine running 370 microcode load
able to execute 370 at about 80kips ... and 2-8 other (identical
microengines) with various microcode loads to perform various kinds of
i/o controller functions. A 370/125 was identical to a 370/115
... except the microengine executing 370 microcode load was about 50%
faster, able to execute 370 instructions at about 120kips.

The microengines executed an avg. 10 native instructions for every 370
instruction ... so the native performance of the 115 engine was around
800kips and the native performance of the 125 engine was around
1.2mips.

since there was no processor caches (this were slower microprocessors
that didn't have the performance mismatch between processor speed and
memory speed) ... and the system didn't run similar microcode loads
... there was less problem with multiprocessor coordination
... although the processors executing i/o controller functions were
responsible for "executing" channel programs ... which could also be
operated on by the processor running 370 microcode.

John W. Backus, 82, Fortran developer, dies

Andrew Swallow <am.swallow@btopenworld.com> writes:
BAH we are not talking about a 5 ton Cray from 30 years ago but a
single chip smaller than a finger nail. One microprocessor chip
containing 80 X86 family CPUs (cores). It is designed to go into
standard home PCs in 2 years time.

from above:
Intel's prototype uses 80 floating-point cores, each running at 3.16GHz,
Justin Rattner, Intel's chief technology officer, said in a speech
following Otellini's address. In order to move data in between
individual cores and into memory, the company plans to use an on-chip
interconnect fabric and stacked SRAM (static RAM) chips attached
directly to the bottom of the chip, he said.

and with a little help from IBM becomes 1025 cores ... with the addition
of a single powerpc core.

but as per this post ... there is significant barrier with regard to
existing programming paradigms and being able to effectively utilize the
cores:
http://www.garlic.com/~lynn/2007i.html#78 John W. Backus, 82, Fortran developer, dies

also had ref to last yrs hotchips ... which had a number of
presentations by cellphone companies about high-performance, low-power
multicore chips ... able to process highly compressed full-motion
video.

has a lot of stuff sliced and diced in a number of different ways for
salary/wages, benefits, fully loaded compensation for period 1991 to
2005. For instance, avg total (fully loaded) compensation in 2005 for
all workers in companies with >500 workers was $33.48/hr.

so foreign automobile companies did a couple different things when
import quotas were instituted. one was move from cars at the low-end
to cars at the high-end (i.e. the import quotas were on the number of
cars ... so change from selling cars less than domestic vehicles to
selling same number of cars at the high-end).

the other tactic was start building cars in the US. one of the
comments from the time was that they were use to being able to hire
high-school graduates to perform the work. however, in the US they
were finding they needed to require at least 2yrs college (junior
college degree) in order to get people with at least high-school
education.

some vendors would market SMPs (only) with redundant and/or
partionable configurations. for instance, in the 60s, for the 360
two-processor SMPs, it was always possible to split them and run as
two, independent single processor machines. this continued thru the
370s up until the 3081 ... where they attempted to introduce to the
term "dyadic" to differentiate it from the earlier configurations that
could be partitioned into independent operations.

whether or not a particular vendors SMP was error-tolerate or not was
more by convention than part of the industry definition of SMP.

recent post mentioning DEC press release moving from asymmetrical
multiprocessing to symmetrical multiprocessing support (circa spring
'88) ... i.e. they may have been SMP in the "shared-memory processing"
sense ... but hadn't been SMP in the "symmetrical multiprocessing"
sense:
http://www.garlic.com/~lynn/2007.html#46 How many 36-bit Unix ports in the old days?

not that this was also referred to as "tightly-coupled" in mainframe
circles ... to differentiate from "loosely-coupled" (i/o sharing but
not memory sharing). tighly-coupled tended to be less fault resistant
because common code (in common memory) could result in failures ...
recent post mentioning study that indicated starting at least in the
early 80s, hardware represented smaller and smaller portion of the
cause of failures:
http://www.garlic.com/~lynn/2007h.html#76 John W. Backus, 82, Fortran developer, dies

i.e. loosely-coupled and/or cluster implementations are somewhat
easier to create geographically distributed failure recovery
implementations. Also, as both hardware and software have gotten more
reliable ... environmental problems/failures rise to the top of the
list of common source of outages ... and as cost of hardware and
transmission bandwidth have fallen, more and more services find that
they can justify geographic distributed failure recovery (for
continuous availability).

mentions an old article calling for 100percent tax on (massive)
unearned profits in the automobile industry in the wake of the import
quotas.

the article claimed that the purpose of the import quotas was to give
the domestic automobile industry breathing room to remake themselves
into a competitive body. the reduction in cheap imports would lesson
the downward pressure on prices charged for domestic cars ... giving
them increased profits which could be funneled into remaking their
business. The article observed that instead, the (significant)
increased profits went into increases in workers and executives
salaries/bonuses and stock dividends.

There were also secondary effects ... with the foreign importers
observing that they could sell as many high-end cars as low-end cars
... totally changed the type of car they sold. This almost totally
eliminated the downward pressure on domestic car prices ... supposedly
allowing domestic manufacturers to nearly double the price of the same
automobile over a period of a few yrs.

There were other secondary effects ... the motivation to the foreign
importers to totally change the type of car they sold ... also
contributed to changing how they did car development ... cutting the
traditional 7-8yrs elapsed time to 2-3yrs. Some of the effects of this
could be eventually seen in the early 90s behind the "C4" effort in
the domestic car industry, which was targeted at leveraging
(primarily) IT/dataprocessing technology to cut the traditional 7-8yrs
lead time to come out with a new model (aka yr to yr changes tend to
be mostly cosmetic) to 3yrs (in order to finally(?) compete with
foreign operations).

one of the issues behind C4 ... is that as long as car buying habits
remain relatively static ... there isn't much to differentiate 7-8yr
development cycle and 2-3yr development cycle. However, when buying
habits go into same amount of flux and change ... being able to
respond to what the customers are buying in 2-3yrs (or less) gives a
significant advantage over organizations that take 7-8yrs to respond.

they weren't suppose to do multiple microprocessor common bus
implementation. it is now long ago and far away (35yrs) ... but i have
vague recollection that it may have involved some domestic plants
complaining that Boeblingen had done a more advanced/competitive
design

Display Technologies Evolution

Brian Inglis <Brian.Inglis@SystematicSW.Invalid> writes:
Monochrome plasma panels were also used at one point in products such as
the IBM 3190 Information distributor, which had four times the
resolution of a normal 80x25 screen, and could be used to display 1-4
logical screens, with a maximum single screen capacity up to 132x60 (a
normal lineprinter page at that time).

from above:
IBM took an early interest as well, and the lure of Big Blue's prestige
and deep pockets forced Merriam and Alpert into some ticklish
negotiations between the two corporate players, with the happy result
that U of I collected a million dollars from IBM in exchange for another
license. That license would lead in 1983 to the IBM 3290 Information
Panel, "the industry's first mass-produced, large-screen plasma display
terminal for commercial use," according to an IBM advertisement.

strange FTP problem--transatlantic asymmetry

patrick.peters writes:
What kind of a problem gives you good latency numbers but poor
application performance? What kind of problem only shows up when the
big data flows move east?

routing doesn't have to be symmetrical, bandwidth/traffic shaping
doesn't have to be symmetrical, individual physical links may not be
symmetrical, contention may not be symmetrical (aka link may be
symmetrical but dominant traffic flow may not be symmetrical, aka lots
of traffic from servers in the west to clients in the east).

traceroute from both ends may give whether the hops are the same
(symmetrical routing)

large packet traceroute (from both ends) may give whether the
transmission latency over each individual hop is symmetrical.

Small packets may give similar latency for similar hop ... even if
bandwidth/traffic of the links are significantly different (or different
in different directions). traceroute with different port numbers might
turn up port-number specific traffic shaping.

bandwidth/traffic shaping can occur at ip layer and may even be
udp/tcp/port specific ... and can be asymmetrical. asymmetrical
bandwidth can also occur at lower levels.

Problem with TCP connection close

David Schwartz <davids@webmaster.com> writes:
Unfortunately, TCP takes resources and times to start up and shut down
a connection. There's no a whole lot you can do about this. There are
known serious hazards with trying to reduce the TIME_WAIT interval.

mid-90s HTTP webservers encountered significant TCP scale-up problem
with common implementations that had linear scan of FINWAIT list. the
problem was that some loaded webservers were cycling TCP sessions so
fast (resulting in quite lengthy FINWAIT lists) that several of the
major webservers were hitting 100% processor busy and spending nearly
all of that scanning the FINWAIT list. Several vendors relatively
quickly put together new releases that significantly reworked how
FINWAIT list was handled.

there has also been work on reliable transactions protocols that had
fewer minimum packet exchange ... i.e. like VMTP/RFC1045 with 5 minimum
packet exchange.

Anne & Lynn Wheeler <lynn@garlic.com> writes:
one of the things that started to show up with interactive computing
was games. in the 70s, tymshare had ported the adventure dec fortran
source to vm/cms and i obtained a copy for internal corporate
distribution. at one point, the executives in STL complained that they
thot nearly everybody was spending their days playing adventure on
vm/cms (instead of doing dbms development). recent post mentioning
adventure:
http://www.garlic.com/~lynn/2007g.html#0 10 worst PCs

STL (south san jose, dbms and language development, subseqently renamed
the silicon valley lab) and Hursley (UK, communication and cics
development) looked at off-shift dataprocessing offloading in 1980. The
dominant development platform at both locations was vm/cms interactive
computing. like in the reference to palo alto vm/cms this sort of
interactive workload tends to be running at full capacity during first
shift with much lower off-shift use.
http://www.garlic.com/~lynn/2007j.html#13 Interrupts

the strategy was to get a "high-bandwidth" double-hop satellite link
between STL and Hursley (i.e. from west coast up to the geo-sync
satellite over the US, down to the east coast, up again to geo-sync
satellite over the atlantic and down to Hursley). Since there was 8hr
time-difference ... some of the 1st shift Hursley workload could be run
on the STL machines (being 3rd shift in california) and some of the 1st
shift STL workload could be run on Hursley machines (being 2nd shift in
UK).

This was going to be showcase operation ... so some of the strategy
people stepped in to "force" the link to operate with MVS JES2/SNA (even
tho the dominate operation was vm/cms which didn't use SNA for network
links).

They tried to bring up JES2/SNA on the link ... and nothing happened.
Somebody then suggested to try it with VM link just to check things out
... and it came up with no errors. They immediately switched back to
JES2/SNA on the link and nothing happened. The "official" conclusion was
that there was significant transmission errors on the double-hop
satellite link and VM link error handling was too primitive to recognize
the problems. The actual situation was that the JES2/SNA had built in
round-trip timeout ... which the round-trip double-hop satellite
propagation delay was exceeding (and which they couldn't "fix") ... but
the VM link support did adjust for the round-trip (double-hop satellite)
propagation delay.

for other MVS JES2 topic drift between San Jose and Hursley ... old
post mentioning (unless converted) network traffic between different
versions of MVS JES2 (with incompatible network traffic headers) would
result in JES2 failure that would also bring down the MVS system
http://www.garlic.com/~lynn/2006x.html#8 vmshare

Disc Drives

scott@slp53.sl.home (Scott Lurndal) writes:
The real question is what is the MTBF for drives that spin-up/spin-down
vs. the MTBF for drives that stay up all the time, and is the difference
significant.

doesn't mention spin-up/spin-down frequency related to MTBF ... but does
look at lightly loaded versus heavily loaded. slightly surprising is
that after 3yrs, heavily loaded disks tend to have slightly better MTBF
than lightly loaded disks (with possible explanation that less reliable
heavily loaded disks tended to not make it to 3yrs).

Dave Wade wrote:
I know there is no commercial value in it, so it won't
happen, but wouldn't it be nice if IBM realeased a
software emulation that worked like the original
XT/370 that emulated both the Hardware and CP calls
and so would allow CMS itself to be run native on
Linux or Windows...
.. oh and of course would license CMS for such
an evironment.

XT/370 was codenamed washington ... stripped down CP kernel running on
modified 68k processor that provided 370 emulation (for problem and
some privileged instructions). The "370" had its own dedicated
processor memory. Running under dos was a program called "cp/88" and
the CP kernel would communicate with "cp/88" for emulation of I/O
operations (i.e. cp/88 provided real device i/o support and
communicated back and forth with the cp kernel).

the original model had 384k "370" memory ... and I did some
application studies which showed that after the fixed cp kernel memory
requirements ... that cms applications frequently would "page thrash"
in the remaining real memory. Exaserbating the problem was that all
disk i/o (both cp paging and cms file i/o) involved communication with
cp/88 which would then simulate the operations on XT hard disk that
had 110millisecond avg. access.

the publishing of the elapsed time & page thrashing results
resulted in a corporate decision to ship the product with 512k "370"
memory ... which involved a six month schedule slip ... which lots of
people blameed on me.

However, in this time window ... I was allowed to incorporate an
enhanced page replacement algorithm (over and above what i was able to
ship in the vm370 resource manager) ... and CMS "paging access method"
filesystem support ... i.e. page-mapped operation ... which I had
originally done on cp67/cms ... but never shipped in standard vm370
release.

the problem was that normal CMS operations are highly disk intensive.
DCSS sharing of applications on mainframes were somewhat able to
compensate for some of this (by having programs & applications
already available in real storage because of use by other users).
However, in the xt/370 configuration none of this was applicable ...
there wasn't enuf real storage for such caching ... and since it was a
single user system ... there wasn't any "sharing" use. however, I had
demonstrated avg of 300percent (or better) thruput improvement with
the paged mapped cms filesystem support for disk intensive
operations. The page mapped CMS filesystem support also allowed for
asynchronous operation on program loading ... allowing large block load
of CMS "module" into whatever available real storage ... but also
allowing some asynchronous overlap of CMS application execution with
loading of the program (keeping all the asynchronous activity straight
and hidden from cms by playing games with page invalid/valid
bits). The page mapped CMS filesystem support also had some
enhancements for attempting to do contiguous (physical) allocation
when MODULE was generated (and/or written to disk) ... which could be
subsequently leveraged when program was loaded.

the same adapter board was later made available in ATs and called
AT/370.

post that includes list of source update files that I had to the cp
kernel as part of A74 support ("dmkpam" is the source routine
containing the cp changes supporting paged mapped operation).
http://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions

Alan Altmark wrote:
Well, it's been nigh on 40 years that CMS has been around. Seems like a
committment to me. CMS is here to stay. If all the people with z/OS
get z/VM and [re]discover CMS, who knows what might happen? "Never say
die!"

well, cms (as in cambridge monitor system) started on cp40 (cambridge had
gotten a 360/40 and did the hardware modifications to implement virtual
memory ... pending getting 360/67) ... cambridge got 360/67 in 1967 and
morphed cp40 into cp67 ... so it has been 40yrs (in part, CMS work
could even start on real 360/40 before cp40 was operational)

from Melinda's history
http://www.leeandmelindavarian.com/Melinda/
By September of 1965, file system commands and macros already looked
much like those we are familiar with today: ''RDBUF'', ''WRBUF'',
''FINIS'', ''STATE'', etc

... snip ...

cambridge installed cp67 out at lincoln labs in 1967 and then last week
in jan68 came out to install cp67 at the univ where i was undergraduate.
Note, that in jan68, the cp67 people were still apprehensive about CMS
filesystem ... with cp67 source, assemble, and build still being done on
os/360.

in the morph of cp67 to vm370 ... they changed the cms name to
conversational monitor system.

major change in cms from cp67 to vm370 was a little re-arranging of cms
kernel in anticipation of 370 (r/o) segment protection. However, in
doing the virtual memory hardware retrofit to 370/165 ... they ran into
problem with schedule slipping. In order to regain six months in the
schedule for 370/165 virtual memory, they dropped r/o segment protect
and some number of other features from the original 370 virtual memory
architecture (and to have compatibility across the 370 product line
... the same features had to also be removed from other 370 models that
already had implemented the full 370 virtual memory architecture). With
370 hardware r/o segment protect dropped ... vm370 had to revert to the
page protect hack used by cp67 that involved fiddling the 360 storage
protect keys.

It was also in the aftermath of killing FS that POK convinced the
corporation to kill the vm370 product, shutdown the vm370 product group
and move all the people to POK to help accelerate the mvs/xa development
schedule (again attempting to make up lost time in 370 product pipeline
resulting from the FS distraction). Eventually Endicott was able to
salvage the vm370 product mission.

jmfbahciv writes:
Yes, it's "easy" to do with software. The problem was to provide
a computer_system_ no matter what kinds of things died, hardware
or software. The goal was 7x24x360 with 0% perceived MTBFs.

... one of the places we talked to was the telco operation doing 1-800
implementation. they were using a smp fault tolerant platform ... where
hardware/processor failures could be totally masked. 1-800 had
five-nines availability requirement (5 mins outage per yr).

there was small issue ... kernel software maint. required taking down
the system i.e. being "shared memory multiprocessing" ... all
processors shared the same kernel image. Typical scheduled maint. for
such an event could blow the five-nines outage budget for a century.

in the ha/cmp scenario ... having multiple "loosely-coupled" systems
... allowed any kind of downtime on any specific system (unscheduled
hardware/software failures, scheduled hardware maint, scheduled software
maint) ... to be totally masked by the availability of the other
systems. this could be done with less-expensive traditional non-fault
tolerant hardware ... although by that time ... regular hardware was
getting very reliable ... ref to the study done in the early 80s about
outages due to hardware failures becoming smaller and smaller fraction of
total outages.

The issue then was whether the fault-tolerant solution would
require a loosely-coupled installation of multiple fault
tolerant systems in order to achieve the same "availability" of
the non-fault tolerant ha/cmp configuration ... in which case,
what was the justification for having the (additional) expense
of fault-tolerant hardware at all?

There is an analogy here to disk RAID operation ... redundant array of
inexpensive disks ... redundant array of inexpensive processors may be
much more cost effective than traditional fault-tolerant
hardware (especially as "normal" hardware reliability has continued to
improve).

i've mentioned before in the past decade we had some discussions with
one of the larger financial transaction networks ... they had
attributed their 100percent availability over the previous several yrs
to

which saw very little uptake until sysplex (one of the reasons she
didn't stay very long in that position) ... except for the ims
hot-standby work. the financial transaction network had triple
redundant ims hot-standby configuration in two separate geographically
distributed datacenters.

these days ... the only practical way of approaching 100percent
availability is with geographical dispersed operation ... i.e.
when we were doing ha/cmp, we coined the terms disaster survivability
and geographic survivability to differentiate from disaster/recovery
http://www.garlic.com/~lynn/submain.html#available

for other drift ... tandem had bought atalla (and compaq had bought both
tandem and dec ... which hp subsequently inherited when they bought
compaq). this has reference to conference sponsored by main atalla sales
& marketing guy (hosted at tandem in cupertino):
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security

which continued to be marketed under the perkin/elmer brand when
perin/elmer bought interdata. the atalla "sponsor" of the above
mentioned conference, once made the comment that in the early 80s he
made quite a good living selling the boxes to NASA and other gov.
agencies. He also mentioned that the "wire-wrap" mainframe channel
attach board appeared to have still been the original design that had
been done in the 60s.

more than one lab commented that they were discontinuing their large ibm
mainframe operation because they had outstanding REQs for system support
people for over a year that they were unable to fill. The school systems
were turning out lots of unix skills ... but few ibm mainframe skills.
they were having to compete with commercial companies, like in the
financial industry, for the increasingly scarce ibm mainframe system
support skills.

somewhat unrelated, i've heard of some people that jumped from the army
to silicon valley in the late 90s and quadrupled their salaries (unix
sysadmins).

IBM Unionization

Anne & Lynn Wheeler <lynn@garlic.com> writes:
more than one lab commented that they were discontinuing their large
ibm mainframe operation because they had outstanding REQs for system
support people for over a year that they were unable to fill. The
school systems were turning out lots of unix skills ... but few ibm
mainframe skills. they were having to compete with commercial
companies, like in the financial industry, for the increasingly scarce
ibm mainframe system support skills.

said that he had to do presentation to the executive board on major
threats and vulnerabilities ... at the top of the list was most of the
(mainframe) system support people had reached the age where their
mortgages were paid off, their children were all through college and
they had no real motivation to not retire (and there didn't seem to be
any feasable way of backfilling the skills)

Please colleagues, allow my to clarify by stating :
SET FAVORITEEXPLETIVE=''
1. I do not believe "other platforms" are &favoriteexpletive.
2. I am not arrogant and certainly not blind.
3. I am not responsible for the mainframe market share situation. I neither
buy nor sell mainframes.
4. I have heard the costs of hardware and software, but I still believe
arrogance is no cost.
5. I do understand the competition (&favoriteexpletive).
6. Recent young graduates are free to work on any platform of their
choosing. Undoubtedly the market influences
their choices.
7. I do believe the learning curve for Novell, circa 1995, was orders of
magnitude less than zOS + subsystems, circa 1995.
So fast forward 12 years, is learning to be a PC based network "sysprog"
more difficult than zOS, less so, or about the same?
Please note, final question is posed without beliefs, opinions, standpoints,
political biases, or prejudices. I reserve the right to invoke arrogance at
some later date.

from afc ng thread ... w/regard to post referencing some national labs
... discontinuing mainframe systems in the 90s because of inability
to fill positions for system support (schools were turning out lots of
unix skills but little or no mainframe skills). It wasn't a particular
cost issue, it was an issue about being able to find/hire the (scarce)
skills.

part of the problem is getting into a negative feedback loop ...
programs to turn out mainframe skills can take a decade ... once it
starts the reputation about skill shortages can contribute to choices
made about platforms to use ... and the choice about platforms to use
can contribute to choices about skills required.

for totally other topic drift ... in the very early 80s, the disk
division had a PC network server project ... part of the
implementation was being done under a work for hire contract by people
in Provo. For a while, one of the people on the project was commuting
between San Jose and Provo nearly every week. At some point, the
corporation decided to cancel the project ... and allowed the group in
Provo to retain rights to the work they had already been paid for.
Not long afterwards there appeared a PC network server company out of
Provo.

"jerry chapman" <jerryc314@sbcglobal.net> writes:
I am updating an Excel spread sheet with oorexx. Under certain condition I
would like to email the spread sheet to someone as an attachment. Is there a
way I could do that?

from long ago and far away ... REXX exec used for generating tcp/ip
email (actually it took existing email in numerous formats and coverted
them to 822 format)

Dave Garland <dave.garland@wizinfo.com> writes:
You don't think that American schools are capable of producing workers
with equivalent education and skills? If American schools are so
crappy, why do people from around the world want to go to school in
them? You don't think that if HR paid "TREMENDOUSLY" more, the field
would attract more qualified domestic engineers? That (more) smart
people would go into engineering instead of plastic surgery or Harvard
Business School?

there are k12 school systems and then there are institutions of higher
learning.

as i mentioned here ... curriculum for entering freshman had
to be dumbed down three times between late 60s and early 90s
... primarily because of "domestic" students
http://www.garlic.com/~lynn/2007j.html#45 IBM Unionization

on the other hand ... more recently NSF has been concerned about the
dramatic increase in the number of technical graduates from foreign
universities ... post
http://www.garlic.com/~lynn/2007i.html#79 John W. Backus, 82, Fortran developer, dies

i didn't mean to imply that the fault tolerant server that was being
used by the 1-800 (telco) guys was from same vendor ... in fact it was
from totally different vendor.

my impression was that a (software) system upgrade for the fault
tolerant server vendor ... i.e. system build and related system files
on disk, kernel image on disk, kernel image in processor (shared)
memory ... required taking exclusive control of those resources to
replace existing copies with new copies. It would happen periodically,
even if only once every yr or so.

it isn't code ... it is a "package" file description ... used by
toolsrun (also implemented in rexx) ... somewhat analogous to README
file.

toolsrun provided all sorts of function ... it had listserv type
function for email distribution lists ... for conferencing and file
distribution (like application packages). it also had support for
repositories ... where local "slave" toolsrun could maintain the same
kind of information that might be distributed via email, sort of being
able to operate either in listserv mode and/or more similar to early
usenet.

in the late 70s and early 80s ... I had been doing some semi-automated
computer conferencing type stuff on the internal network. at some point
top executives became aware of the situation ... and there was an
"investigation" ... one of the outcomes was decision to have some
official corporate supported computer conferencing facilities ... which
then contributed to the wide-spread deployment of toolsrun.

there was also a researcher hired to sit in the back of my office and
follow me around for nine months ... investigating how i communicated
(face-to-face, telephone, etc ... they also had copies of my incoming
and outgoing email as well as all of my instant messages). The resulting
research report was also a Stanford PHD thesis (joint between language
and AI depts) ... and the material for subsequent books and papers.
somewhat related posts
http://www.garlic.com/~lynn/subnetwork.html#cmc

John W. Backus, 82, Fortran developer, dies

jmfbahciv writes:
Even if security was designed in, allowing pieces of the executing
code to be part of the kernal will defeat any and all security
designs. It is similar to laying 1000 rattraps around the cheese
building after the rats have all moved in.

IBM Unionization

kkt <kkt@zipcon.net> writes:
Fortunately, American higher ed is pretty good and makes up for most
of the inadequate high school preparation by the time lower division
classes are completed. Thus, American colleges still attract a lot of
foreign students.

earlier apprehension was that since so much of domestic high-tech
industry was being fueled by foreign graduates, who stayed in the states
... that it possibly only required slight changes in the relative
standard of living between here and their home country ... to result in
mass migration back to their home countries.

in fact, numerous of these foriegn graduates (getting 4.0) are here paid
for by their home govs. ... and directed to stay on, spend 5-10 yrs in
high-tech employment and then return home ... as "tech transfer". Some
surveys had even found some of the leading edge corporate high-tech
departments totally composed of such foreign employees (obligated to
return home after graduation and spending 5-10 yrs working in leading
edge, high tech activities).

"Micheal H. McCabe" <mhmccabe@alltel.net> writes:
(10) The sad state of educational affairs in much of America is on-par with
the worst conditions found in some third-world countries. The only people
we can blame are ourselves for letting it get this bad. As a society, we
allow hack politicians to play games with our educational infrastructure.
We allow our tax dollars to be wasted on programs of questionable value. We
accept simple answers to complex questions and we allow untenable concepts
of forced educational equality to bring down our best and brightest minds.
We need change in our educational system that is more revolutionary than
evolutionary.

• The average composite literacy score of native-born adults in
the U.S. was 284 (Level 3); the U.S. ranked 10th out of 17
high-income countries;
• The mean prose literacy scores of U.S. adults with primary or no
education, ranked 14th out of 18 high-income countries;
• The mean prose literacy scores of U.S. adults with some high
school, but no diploma or GED, ranked 19th out of 19 high-income
countries;
• The mean prose literacy scores of U.S. adults with a high school
diploma or GED (but no college), ranked 18th (tie) out of 19
countries;
• The mean prose literacy scores of U.S. adults with 1-3 years of
college, ranked 15th out of 19 countries;

... snip ...

and more recent statistics show declining situation over the last
decade or so from the earlier studies

IBM Unionization

D.J. <alphmoe23@cableone.net> writes:
What is funny/sad about it is most of them died from over work at
those manual labor jobs they kept telling me was the only honest
work. They felt that anyone who worked indoors was not earning that
money.

from above:
But that was just the beginning of her ordeal. For two full weeks after
Poor reported the crime to her bank, her imposter continued to withdraw
money from her account as fast as she added it. As a result, she was hit
with 20 overdraft fees totaling $670, and nearly six weeks after the
fact, she was still fighting to get all her money back.
...
Banks constantly market their zero liability programs, which aim to
convince consumers that they stand to lose nothing from most cases of
identity theft.
...
But these reports rarely discuss the more challenging problems connected
with the theft of debit card or checking account data theft. Getting a
credit card company to waive fraudulent charges may be hassle-free for
most people, but beating back electronic transfer fraud – usually
carried out via cloned debit cards or counterfeit checks -- is another
matter entirely.

... snip ...

the blog comments following the above article must be 50 times longer
than the original article.

I was in the Army (over in Germany) and our base was a 'stepping
stone' for generals. They came in a 1 star and one year (more or
less) later they became a 2 star. We weren't even close to the
trench's (so to speak) we were a "command" so no one really got hurt
(per se) by any screwups the General may have caused. In a side issue
(humorous) one of our subordinate bases when polled at 11PM reported
they were under attack by the communist. Since they reported an
attack we had to wake up our General to inform him of the situation.
The colonel (IIRC), in charge of that base, was reduced in rank to a
Captain(?) and was basically told to retire. All this from a sergeant
who couldn't read a code book.

...
"There are two career paths in front of you, and you have to choose
which path you will follow. One path leads to promotions, titles, and
positions of distinction.... The other path leads to doing things that
are truly significant for the Air Force, but the rewards will quite
often be a kick in the stomach because you may have to cross swords with
the party line on occasion. You can't go down both paths, you have to
choose. Do you want to be a man of distinction or do you want to do
things that really influence the shape of the Air Force? To be or to do,
that is the question." Colonel John R. Boyd, USAF 1927-1997

... there have also been corporate stepping stone positions ... for
individuals that got put on "fast track". Woe was you if the head
position of your organization was designated as a "fast track" stepping
stone ... there could be turn-over in the position every six months
(executives playing musical chairs).

IBM Unionization

jmfbahciv writes:
But that is what matters for those reports. Have you ever been
involved in the beige book planning of those companies? Have
you ever participated in a bullshit session that decides which
direction the work is going to go? We had ideas of what we
were going to do 5 releases from now. This was necessary
because some of the ground work had to be out in the field
and established for certain future implementations.

5yr plans and what really happens are the difference between strategic
and tactical ... very boyd, i've considered boyd the greatest strategic
thinker that i've ever interacted with (and he could simulataneously
plan for tactical within strategic structure)
http://www.garlic.com/~lynn/subboyd.html

"Michael N. LeVine" <mlevinespmfltr@redshift.com> writes:
Is stiction still a problem? Thats when the heads resting on the
surface of the disk sometimes adhere then get torn off or bent out of
alignment when the disk is started up again.

some early 3380 drives (floating thin-film heads) had stiction problem
... but was variable ... some batches with no problem at all. lots of
quality control and manufacturing monitoring and forensics for six
months to try and identity what coorelation was ... but also tweaking
processes and formulation ... so i don't remember if the original
culprit was ever definitively identified.

Steve Samson <ssamson@dc.rr.com> writes:
I would regard SP as the "inside" job, designing, writing, testing,
and integrating code to accomplish some well-defined purpose. An SE
would be on the interface between "inside" and "outside", meeting with
TPTB and the end users to arrive at a set of specs that would then be
reviewed and/or revised with the SP to assess cost and schedule, thus
defining the purpose of the SP's effort.

In the dawn of history, an SE was the IBM sales team member who would
provide on-site training and act as the level 1 contact for solving
problems. By 1965 the SE became not much more than the guy you called
to order manuals, as all of them with half a brain were pulled into
the S/360 development effort.

Just my opinion and recollections...

big change was 23jun69 with unbundling announcement and charging for
SE time (along with charging for software and other services). prior
to that, a lot of SEs got "hands-on" training at customer installations
doing real-live technical things (sort of on-the-job training after
introductory school). after 23jun69 announcement, customers were less
likely to pay for SE "services" ... especially younger ones getting
their on-the-job training. that sort of created two-class system ...
those that had hands-on experience prior to 23jun69 ... and customers
were more likely to pay for their time ... and those that came after
23jun69.

before 23jun69, for a period as an undergraduate, i had responsibility
for the univ. production os/360 system (and also got to play with cp67).
I had done a lot of stuff to significantly soup up mft (and then mvt)
thruput ... part of of it doing carefully crafted sysgens. There was a
period where I would see brand new SEs in the branch office (fresh out
of corporate schools) for 3-4 month period and then be replaced by new
batch (getting their "hands-on" by "helping" me).

cp67 (virtual machine) system on a few 360/67s at locations around the
states and remote login access from branch offices ... being able to
use dos/360, os/360, etc (i.e. motivation for the original "hands-on"
in the HONE acronym).

the focus somewhat changed after science center did the port of
apl\360 to cms for cms\apl and the explosion in the number apl
applications supporting sales & marketing appeared ... like the
"configurators". Early in 370 product time-frame ... there was
transition where sales couldn't even submit orders until after they
had been processed by HONE configurator. The explosion in the use of
HOME by direct sales & marketing sort of swamped the processors
and there was then transition away from its original purpose of
allowing SEs to get "hands-on" system experience.

HONE would migrate (from cp67) to vm370 and eventually had HONE
(clone) systems sprouting up all around the world ... some of the
early ones, i even got to do the installation. Many of the HONE APL
modeling applications would also permeate hdqtrs locations (in
addition to direct branch office sales & marketing support). One
of my first HONE installs outside the US was when EMEA hdqtrs moved
from NY to La Defense (outside Paris) in the early 70s.

mark.zelden@ibm-main.lst (Mark Zelden) writes:
Today, I see these two used interchangeably. I've even seen title changes
from one to the other in the same shop when HR decided to review
everyone's job titles and such.

I still prefer plain ol' Systems Programmer over all the titles I've had.

later, i would have battles to have no title at all ... and have my
business cards w/o any title (I would sometimes joke that if it was
necessary to get things done based on a title ... then it was time to
retire ... i should be able to convince people to do something based on
it was the right thing to do).

the other battle was being one of the first to have email address on
business card.

which is more along the lines of references at some number of locations
(across a variety of large bureaucratic organizations) being primarily
mushroom factories (i.e. most of the people are kept in the dark
and feed .... )

Ben Rudiak-Gould <br276deleteme@cam.ac.uk> writes:
The banking industry uses open encryption algorithms like 3DES and
AES. They'd be crazy not to, because designing a secure encryption
algorithm is (empirically known to be) extremely difficult, and it's
(again empirically) very dangerous to trust a design that hasn't been
thoroughly vetted by a large number of experts. It's not enough to
have an expert design the algorithm, because they routinely fail to
notice attacks. This goes for every aspect of a secure

in part because there was requirement to make sure things were aligned
with the actual business processes ... as opposed to possibly being
totally unrelated to any practical use.

part of this was because it was in the heyday of "PKI is the answer, now
what is the question?" ... and the adding of digital certificate processing
to existing payment transactions was resulting in factor of two orders
of magnitude (100 times) bloat in both payload size and processing
overhead:
http://www.garlic.com/~lynn/subpubkey.html#bloat

the issue is more along the lines of risk adverse in disputes and where
the burden of proof lies. a financial institution electing to not use a
"standard" will find that they have a significantly more difficult
burden of proof placed on them in any dispute/litigation. this has
actually shown up in at least one litigation dispute in europe ... where
the plantiff claimed damages (and prevailed) from financial institution
in a an unexplained large financial transaction and only cited DES as
still being used (after it had been depreciated). as a result, the
burden of proof fell on the financial institution to prove that the
continued use of DES could not be a factor.

there was some additional transformation when NIST announced that it no
longer needed to create standards from scratch ... but could cite as
standards, work done by other bodies ... like X9F (I think the first
instance was x9.62 having to do with elliptical curve cryptography).

Disc Drives

"Michael N. LeVine" <mlevinespmfltr@redshift.com> writes:
Are you sure it was just limited to that IBM drive? If memory serves
me this problem also showed up occasionally on other drives and not
just IBM's

rfochtman@ibm-main.lst (Rick Fochtman) writes:
I went "the other way" in the Army, finding myself in a tropical
climate where the main diet was rice, with a few vegetables and maybe
a water buffalo, when the gunner "forgot" to clear the M2-HB before
attempting to "clean" it. In my (somewhat limited) experience, the
officers were there to get some combat time, and pay, into their
service records, as a stepping stone to further promotion. Net
result: the sergeants ran the Army while the officers "fought the
battles" and collected the medals. Needless to say, I have a very low
opinion of high-flying "leaders" that don't share the hardships of
those who are "led".

Phil Hobbs <pcdh@SpamMeSenseless.pergamos.net> writes:
I remember TOOLSRUN very fondly. All the IBM internal forums used to
use it, as well as the internal tool distribution discs. I wish I had
a newsreader with the comfort features of FORAVIEW!

the only conflict that I'm aware of with HSDT RSCS drivers are a
current conflict with the TOOLSRUN exec (the REXX exec from <<rexx
author>> that handles all the tools disks). The REXX exec expects that
for files that originated from VM nodes, the second NOP/TAG record (i.e.
RSCS control information) alwas contained the origin nodeid & userid. If
that is not found in the 2nd record, TOOLSRUN rejects the file.

As part of improving the efficiency of HSDT links, the RSCS line driver
code to do character compression was removed (it was determined that the
cpu overhead was costing much more than the transmission time savings
... i.e. actually ran slower). With that change, "S&F" records began
appearing as the 2nd nop/tag record.

After a bit of analysis, it turns out that S&F records were RSCS
information records that alwas were part of the file, but somewhere in
the far distant past a change to the compression code inadvertantly also
deleted forwarding of S&F records. With the deletion of the compression
code, the S&F records magically reappeared.

There is a simple 3 line change to the TOOLSRUN EXEC to recognize S&F
records and bypass them when looking for the origin information
record. There is a separate 40-60 line change to the TOOLSRUN exec which
generalizes the processing of the nop control information, which
recognizes a large number of different formats based on content (rather
than position). This more complex change also correctly handles
recognition of origin information from MVS/JES systems.

There is currently discussion about how best to resolve the TOOLSRUN
EXEC problem. The removal of the compression code makes sense in a
number of situations ... not just for HSDT links but for other links
where the speed may be as slow as 56kb (i.e. CPU compression overhead
taking more time than the transmission savings of transmitting
uncompressed record).

i.e. while tcp/ip is the technology basis for the modern internet, we
claim that hte NSFNET backbone was the operational basis for the
modern internet.

in related hsdt activity, the mainframe tcp/ip product had been
implemented in vs/pascal. it had several thruput issues; it could
consume a full 3090 processor while only getting 44kbytes/sec
aggregate thruput. I made the modifications to the product to support
RFC1044 and in some testing at Cray research between a Cray machine
and a 4341-clone, was sustaining 4341 hardware interface speed
(1mbyte/sec) using only a modest amount of the 4341-clone processor
(over 20 times the aggregate data rate for less than 1/20th the
processor overhead). past posts mentioning doing rfc 1044 support:
http://www.garlic.com/~lynn/subnetwork.html#1044

she could design features in support of loosely-coupled ... but then
the features had to be justified. this was heyday of buillding bigger
iron and if single processors weren't big enuf .. then go to SMPs. at
the time loosely-coupled didn't get as much attention ... that is one
of the reasons she didn't last long.

she also had constant battles with the "SNA" group ... "SNA" supposedly had
responsibility for terminal communication ... but actually wanted
control over anything that had the words communication and/or
networking. one of the (temporary) truces was that "SNA" had control
over everything that crossed the walls of the datacenter/machine room
(and therefor wasn't supposedly mandated also for everything that might
go between machines within the datacenter walls). semi-related posts
mentioning SNA group and terminal emulation
http://www.garlic.com/~lynn/subnetwork.html#emulation

as I've mentioned numerous of times before, her peer-coupled shared data
architecture didn't see much take-up ... except for by the ims group
doing ims hotstandby ... until much later with sysplex (which is found
in current generation of mainframes):
http://www.garlic.com/~lynn/submain.html#shareddata

An example, battle she fought and lost was over 3088/trotter ... a
"new" channel-to-channel multiple processor interconnect. She had a
bunch of enhancements for it ... but it eventually shipped as a
product with little more than the earlier CTCA (channel-to-channel
adapter) implementation.

John Byrns <byrnsj@sbcglobal.net> writes:
How do you know that the employers didn't honestly believe that they
would be able to pay the bills when they would come due 30 years hence,
that things would proceed as they always had?

What about the ethics of the unions, if it was so obvious that thye
employers wouldn't be able to pay the bills when they came due in the
future, what were they doing making the demands in the first place? I
get it now, the unions get a pass on the ethics issue.

there is some implication that both employers and unions act as if they
are single voiced entity that has extended life. in fact, both employers
and unions are made up of composite of individuals, whose agendas may
have little or nothing to do with any (theoritcal) agenda of the
organization they are suppose to represent.

time-and-time again there are situations where individual agendas appear
to have little or nothing to do with the organization they supposedly
represent. sometimes this difference becomes more pronounced as
individuals near their own retirement age. possibly one last "bonus" or
some other kind of reward is tied to some strictly short-term objective
... and the individual places their personal benefit over that of the
organization's long-term benefit (especially if they are shortly to be
long gone).

semi-related is the saying that "business ethics" is an oxymoron.

my wife was sent to "executive school" (step up from "managers school")
a couple times. one of the things that they do in such environments is
play team building games ... split the group into two teams and play act
on how to resolve issues. one of the scenerios has to do with win-win,
win-loose, and loose-loose strategies. now in real life ... for ongoing
interactions ... win-win tends to build better cooperation and long term
benefits for everybody. however, win-loose may provide significant
advantage, if life is viewed as a one-shot game (or purely a series of
one-shot games). so she had her team play win-win up to the last round
... and on the last round (since in the game, there was apparently no
long term downside), she had her team play win-loose. This brought some
members of the other team nearly to the brink of tears.

John W. Backus, 82, Fortran developer, dies

jmfbahciv writes:
I have never thought of disk as memory even when it was used
exclusively for swapping and when the loosely-coupled TOPS-20
project was happening.

tss/360, future system and other systems from the period had concept of
"one-level store" ... where everything was mapped into virtual memory
paradigm .... disk were for both paging/swapping address spaces as
well as all file operations were done via memory mapped construct.

hancock4 writes:
In this discussion, we must be looking at modern circumstances, not
the excessively greedy unions of the 1960s, and not the hot DP job
market of the 1970s.

individual selfishness doesn't seem to have abatted any ... if anything
it has gotten worse ... with large portion of society members looking at
playing win-loose.
http://www.garlic.com/~lynn/2007j.html#72 IBM Unionization

it isn't the organizations that are playing greedy ... it is the
individual members that compose those organizations that play greedy.
the composite organization may be characterized as being greedy when
that reflects the aggregate behavior of the individual members.

individual benefit, greed and win-loose strategies can be seen at all
levels of social interaction ... from driving behavior on highways to
"business as usual" on wall street. the win-loose strategies can
sometimes have wide-spread disastrous results ... where individuals are
willing to compromise group welfare for relatively small individual
benefit (i.e. the downside of their behavior to the overall group
welfare can be several orders of magnitude larger than the relatively
small individual benefit gained). In some cases, even a million yrs in
jail may not approach the penalty for the damage they do (which is all
out of propotion to their individual gain).

the stuff around sarbanes-oxley is small example. one of the people
that does a TV financial show ... in an interview a couple weeks ago,
stated that when he was involved in day-to-day trading a decade or so
ago ... everybody in the industry practiced stock manipulation on a
regular basis and he has no reason to believe that has changed (and
the regulators apparently have no clue).

Anne & Lynn Wheeler <lynn@garlic.com> writes:
the stuff around sarbanes-oxley is small example. one of the people
that does a TV financial show ... in an interview a couple weeks ago,
stated that when he was involved in day-to-day trading a decade or so
ago ... everybody in the industry practiced stock manipulation on a
regular basis and he has no reason to believe that has changed (and
the regulators apparently have no clue).

for other drift ... this was a very long-winded post ... but includes a
discussion of the aggregate long term financial consequences stemming
from the S&L incident of the 80s
http://www.garlic.com/~lynn/aepay3.htm#riskm The Thread Between Risk Management and Information Security

possibly i have a jaundiced view partly based on past experiance.

recent post about after going on 15yrs, finding out that the new hires I
was interviewing (to work in a new group under my direction) were being
offered 1/3rd more than i was currently making ... and then finding it
tough slogging to argue that I should get a raise so i was making the
same as what new hires were being offered.
http://www.garlic.com/~lynn/2007e.html#48 time spent/day on a computer

the standard telecommunication controller had a "SAD" command that
allowed dynamically associating the type of controller line scanner
with each specific line (i.e. 1052, 2741, tty). The standard cp67
terminal support code provided for 1052 & 2741 support with
dynamic terminal identification and "switching" the appropriate
line-scanner with the "SAD" command.

So when I went to add TTY/ascii terminal support to cp67 ... I
attempted to integrate it in such a way that it would also do dynamic
terminal determination and switching the appropriate line scanner with
the SAD command. All this worked with "hard-wired" lines ... however,
wanted to extend the support to dial-up lines ... so a single phone
number and common dial-up rotory pool could be used for all
terminals. This is where the problem showed up ... since the standard
terminal controller implementation had took a short cut ... hardwiring
the (line baud rate) oscillator to each line (so that while the type
of line-scanner was dynamically assignable to each line ... it wasn't
actually possible to change terminal type when different baud rates
were involved).

the line-scanner in the interdata3 clone was implemented in software
and on initial connection would probe signal rise/fall at very high
rate .... until it figured out where the edges appeared and calculate
the baud rate.

IBM 360 Model 20 Questions

"Nico de Jong" <nico_at_farumdata_dot_dk> writes:
I've only seen 2780's and 3780's as RJE terminals (Denmark). The 3780
was basically a 1442 printer (IIRC) and a 2501 card reader.

after doing tty support for cp67 ... i also looked at putting (crje,
conversational remote job entry) terminal support into HASP
... i.e. borrowing the syntax from the cms editor (the code had to be
completely different because CMS code didn't have to be re-entrant and
HASP code had to be multi-threaded/re-entrant) and the terminal
support from cp67. As part of shoe horning my terminal & crje code
into HASP ... i carefully removed the rje/2780/transparency line
support ... to reduce resident code size and also alleviate some
module addressability issues.

there was supposedly a 360/20 installed in the univ. admin bldg (which
i never bothered to go by and see) ... i had the impression it was
done as sort of an upgrade of some old mechanical tab equipment.

there was the semi-famous incident of a daily (cobol) job that univ.
admin would run on the datacenter's 360. One day the whole place
ground to a whole when the person overseeing the admin run said that
the results were something he hadn't seen before. It turns out that
the application had originated as a 407 plugboard application
... which was converted to autocoder that simulated the 407 plugboard,
which was converted to 709 cobol still simulating 407 plugboard, which
then was converted to 360 cobol) still simulating 407 plugboard. The
last thing the application did was simulate the printing of the 407
sense switches. The problem on this particular day was that there was
an unfamilar (407) sense switch settings. The whole place had come to
a dead halt while it was decided what to do (i.e. all product work on
the 360 was drained). Finally it was decided to rerun the admin job
... to see if the final results printed were the same.

that showed up in a search engine query for 360/20 and RJE (there is a
passing reference).

It also mentions Worley and HASP on 360/65 at Cornell. I've mentioned
before the Univ. sending me on a trip to east coast SHARE meeting along
with a side-trip to Cornell to talk to Worley about HASP. I remember it
well because of catching a DC3 at LaGuardia marine air terminal and
sitting on the tarmack for a couple hrs (w/o airconditioning in
extremely hot, humid air heavily laden with the smell of kerosene)
waiting for a thunderstorm to pass. when we did get off ... it turns out
we were flying through the middle of the storm ... violently bouncing
around and lightening appearing to repeatedly strike the plane and I got
extremely air sick. I staggered off at the first stop (Elmira) and found
a motel to sleep it off. The next morning I rented a car and drove to
Ithaca. A few past posts mentioning that trip:
http://www.garlic.com/~lynn/2006b.html#27 IBM 610 workstation computer
http://www.garlic.com/~lynn/2006c.html#27 Mount DASD as read-only
http://www.garlic.com/~lynn/2006e.html#1 About TLB in lower-level caches

kkt <kkt@zipcon.net> writes:
If you've got a mortgaged house and can't make the payments do you
blame the lender for lending you too much? Would you consider it an
ethical lapse that the lender didn't give you a lower interest rate?

there is something of a difference between unforeseeable circumstances
and things like balloon payments that are clearly written into
sub-prime mortgage contracts ... modulo possibly some significant
proportion of the population that don't understand middle school
arithmatic and/or are functionally illiterate.

Charlton Wilbur <cwilbur@chromatico.net> writes:
If I have two highly lucrative years where I make $200,000 a year, and
I get a mortgage that depends on that income, whose fault is it when
the next year I make $35,000 and the bank forecloses?

i think the simple version of the scenario is statistically
insignificant among all the events that are in the news about problems
in the subprime mortgage market.

The above hypothetical scenario applied to the subprime scenario, is
that a person with two yrs of $200k/annum earnings, signs a subprime
contract for a mansion that will have regular monthly payments of
$20k/month after the introductory period. Doesn't make any difference
whether the earnings stay at $200k/annum (gross), the payments rise to
$240k/annum (after the introductory period). At $200k/annum or
$35k/annum, the bank still forecloses. The subprime scenario is that
the introductory subprime mortgage payments are sized based on current
income ... and then rise to potentially more than even the gross
income after the introductory period.

the majority scenario in the news are the people that got subprime
mortgage ... for the a couple yr introductory period and then becomes
standard variable adjustable. the vast majority have standard hrly
wage that varies little ... and they are possibly barely able to
afford the contracted subprime rate introductory payments ... and then
at the end of the introductory period ... the payment suddenly doubles
or triples (as specified in the contract).

There was basically no reasonable foreseable circumstance where they
were going to be able to afford the post-introductory mortage payment
as stated in the contract (i.e. contractual payments potentially even
larger than gross income).

Various analysts talk about the big boom/bust in the subprime mortgage
market as irresponsible mortgage lenders throwing money at
irresponsible home buyers.

Dave Garland <dave.garland@wizinfo.com> writes:
Your exception recognizes that the circumstances are not seen by some
(who may foolishly be depending on what the agents and brokers are
telling them). Add to that circumstances like job loss and unexpected
medical expenses (especially combined and in that order) that can happen
even to populations who do understand middle school arithmatic and are
functionally literate.

from previous post
The above hypothetical scenario applied to the subprime scenario, is
that a person with two yrs of $200k/annum earnings, signs a subprime
contract for a mansion that will have regular monthly payments of
$20k/month after the introductory period. Doesn't make any difference
whether the earnings stay at $200k/annum (gross), the payments rise to
$240k/annum (after the introductory period). At $200k/annum or
$35k/annum, the bank still forecloses. The subprime scenario is that
the introductory subprime mortgage payments are sized based on current
income ... and then rise to potentially more than even the gross
income after the introductory period.

...

i.e. given a $200k/annum scenario ... possibly the person takes out a
$3.5m mortgage with say an introductory subprime 2.5percent interest
only payment ... around $85k/annum. after the introductory period it
becomes a normal variable mortgage interest+principle ... say
$270k/annum.

also from previous post:
Various analysts talk about the big boom/bust in the subprime mortgage
market as irresponsible mortgage lenders throwing money at
irresponsible home buyers.

jmfbahciv writes:
That is exactly why it should be confidential. You found out
somebody whom you didn't respect made more than you. So you
started a work slowdown. It's a normal human reaction and
behaviour.

There were people who believed that JMF and TW should have been
paid half. EVerybody overlooks longevity and yearly increases
over a long time.

but my scenario was that after nearly 15yrs ... i find that they are
offering new hires (that i was interviewing to work under my
direction) 1/3rd more than what i was making ... and initially when i
raised the subject, they claimed that they had done a detailed study
and i was making exactly what i was suppose to (that was before I
raised the discrepancy between what i was making and what they were
offering the new hires that i was interviewing).

Eric Smith <eric@brouhaha.com> writes:
I was under the impression that the 370/165 and 370/168 microarchitecture
was fairly similar to the 360/65 microarchitecture. Perhaps I'm
mistaken. I haven't seen non-trivial portions of the microcode for any
360 or 370 other than the 360/30.

155, 165, 158, 168 (3830 disk controller) ... lots of high-end stuff
from the 70s ... used horizontal microcode. wide instruction format
that directly controlled various hardware functions with no interlocks
... aka start of transfer from one unit to another ... the programmer
counted instructions/machine cycles ... from the time they initiated
the operation ... until the time that the results should be available.

the low-end and mid-range vertical microcode tended to characterize
the avg. number of (microcode) instructions executed per 370
instruction i.e. ten.

the high-end horizontal microcode tended to characterize the
avg. number of machine cyles per 370 instruction (since some amount of
stuff went on in parallel) ... i remember one of the 165 engineers
making some statement that one of the microcode optimizations going
from 165 to 168 was getting avg. machine cycle per 370 instruction
from from 2.1 to 1.6. then the transition from 168 to 3033 (started
out using 168 wiring diagram mapped to faster chip) got it down to
approx. 1.0.

CBFalconer <cbfalconer@yahoo.com> writes:
By and large I think the education level of HS or College or PHD
graduates has been declining steadily. Today you need a college
graduate to get what most HS graduates used to know.

besides being able to approve a standard w/o having running code, ISO had
a requirement that there couldn't be networking standards work on anything that
violated OSI (crippling its ability to adapt to new technologies and
paradigms):
http://www.garlic.com/~lynn/aadsm27.htm#0 H6.2 Most Standardised Security Protocols are Too Heavy

they profusely apologized ... of course this is all within the last 15
yrs. quite a lot has changed since i first went over their in the
early 70s to do a HONE install ... a recent x-over from another thread
about doing HONE installs in the early 70s (from mainframe n.g.)
http://www.garlic.com/~lynn/2007j.html#65 Help settle a job title/role debate

it was about 20yrs ago when there was this short period that Nippon
Steel was going to buy Oracle. The next qtr, Oracle had signed a
really large enterprise license with one of the oil companies and was
able to back out of the Nippon Steel purchase.

Nippon Steel buying a database company sort of surprised me, so I
looked a little into what was going on. Supposedly, the gov. had
decided that Japan was going to be world leader in information
technology country by 2010. As part of that gov. economic policy all
the profitable manufacturing companies (including automobiles) were
told that they had to invest some specific percentage of their profits
in information technology or have it taken as gov. taxes (of course,
not included was buying computers for corporate operation)

the difference being that all the profitable manufacturing companies
in japan were going ahead and doing the investment to become more
competitive. in any case, as a result, a lot of the technology
investments (in US companies) that went on in the 80s & 90s was
actually coming from overseas (this is separate from recent posts
about the high-tech boom of the 90s in the US was helped significantly
by the large number of highly skilled foreigners with advanced
technology degrees).

strategy/strategic frequently is described as deciding what
needs to be done ... and tactical is deciding on how it gets
done.

one of boyd's highlights on this was with regard to the american army
in ww2 ... was that they had to field a large number of unexperienced
troops ... as a result they went with a very rigid command &
control structure with both tightly controlled top-down strategy as
well as tightly controlled top-down tactical.

the claim could be made that a decision to be the world leader in
information technology by 2010 was a strategic decision ... along with
forcing profitable manufacturing companies to invest at least minimum
of their profits in IT. However, the specifics of such investments
were tactical decisions left up to every company
http://www.garlic.com/~lynn/2007j.html#88 IBM Unionization

my wife's father was engineering combat group. near the end, he was
frequently ranking officer into enemy territory and accumulated a
variety of officer daggers (platinum, gold, silver) in surrenders. he
also liberated some number of camps. supposedly after the end of
hostilities, it was the reason he turned down staying on with a
military district command ... so they posted him to Nanking (instead).

He was graduate of west point with an graduate engineering degree from
UC Berkeley. After coming back from China, he did a "tour" at
MIT. recent reference about co-worker, many yrs later, claiming my
wife's father was his favorite instructor at MIT.
http://www.garlic.com/~lynn/2007j.html#4 Even worse than UNIX

Anne & Lynn Wheeler <lynn@garlic.com> writes:
Supposedly when the company went into the red in 1992 ... they also took
a charge-off to move to fully funded retirement program (i.e. since they
were already in the red, going further into the red didn't make that
much difference). However, a lot of corporations never have bothered to
do that ... assuming that it in the worst case, it can be left up to the
taxpayers to cover the difference at some point in the future. An issue
... also raised by the comptroller general, is that it assumes the
number of taxpayers continue to significantly outnumber the recipients
... there is also a matter of simple middle school arithmatic involved
here to.

i.e. funding the obligation at the time it is incurred ... while the
person is working ... instead of waiting to worry about it when it
comes time to actually pay the pension. article mentions the Pension
Benefit Guaranty Corp (PBGC) and companies with insurance with PBGC
have $340B in unfunded liability. It also estimates that state and
local govs. have $2T in unfunded liability for public-sector
employees. There is some snide reference to legislation has at least
forced chief executives to be (somewhat) more responsible than
politicians. also mentioned somewhat delicate balance of how fast some
of these companies can be forced to makeup for past failures and
transitioning to fully funded obligations (too aggresive could make
the company insolvent)

IBM Unionization

"Del Cecchi" <delcecchiofthenorth@gmail.com> writes:
Your example works perfectly if the 3.5M mansion appreciates to 5 million
in 2 years, and can quickly be sold for a 1.5 million tax free profit
before the teaser rate expires.

IBM Unionization

Charlton Wilbur <cwilbur@chromatico.net> writes:
Now, the union asks for a pension plan that depends on $200 million a
year in profits. The business agrees. Whose fault is it when the
market cools down to $35 million a year in profits and the business
can no longer afford the pension it agreed to?

the issue in the past was that pension plans were not funded at the time
of the obligations ... but were paid out of current operating profits.
fully funded pension plans has the money being placed into the pension
fund as the obligation is being incurred. there is some scenario that
the business has pension funding proportional to the current employees
which is proportional to the current business.

the old time was that there was pension obligations aggreements for the
current employees at possibly 30yrs in the future ... but not providing
current funds to meet those obligations ... planning instead of paying
for those pensions out of operating revenue at that future date.

in some of these old corporate and gov. retirement funding scnearios it
could almost be viewed as pyramid scheme. there are only a few current
retired workers and they are paid out of current revenue w/o setting
anything aside for pension obligations that have to be paid at 30yrs in
the future. this sort of assumes that situation at 30yrs in the future
remains the same as it is today ... there continues to only be a very
small number of retirees receiving funds and the business hasn't changed
i.e. possibly ratio of 100 workers per retiree.

however, at some point in the future ... the ratio of retirees to
workers significantly changes ... which can happen even if the business
stays the same, the number of workers stay the same ... but the life
expectency of the retirees goes up.

in the fully-funded pension/retirement scenario ... the money being set
aside is based on the pension obligation of the current workers. in
effect, money is being set aside out of the current profits, based on
current workers (funding the pension payments for those current
workers). if the business drops off ... there is no issue of having to
take out money to pay for the pension payments for past workers.

in fully funded pension/retirement scenario, there is much tighter
feed-back control between the amount of funding that needs to be set
aside for pensions, the number of current workers, and the amount of
current business. any contract obligations that might have to be
renogiated is if the profit margin for the business changes ... and
cutting the number of workers isn't sufficient adjustment. in a fully
funded pension/retirement scenario ... since each employees future
pension obligation appears as benefits paid against the current work of
the current employees ... the contract renegotiation may reduce size of
direct salary and also indirect benefits (medical insurance, pension
contribution, etc) of current workers. In fully funded
pension/retirement scenario, such renegotiation would have no effect on
the payments to existing retirees ... since that money had already been
payed into the pension fund during the lifetime of those workers.

in the unfunded and/or partially funded scenario ... a downturn in
current business would affect the pension benefits payments for
everybody (since the responsible entities had not bothered to set aside
the funds at the point in time that the pension obligation had been
incurred).

ok, how 'bout this example ... say JMF has 15yrs experience and is the
senior technical person working on a project, was providing technical
direction for the whole project and was asked to interview some recent
college graduates (to join the company to also work on the same
project). The HR department decides that starting salary offer for all
the new hire candidates should be 1/3rd more than the existing salary of
the most senior and experienced person working on the project.

Possibly conversely ... HR department had almost never bothered to
give JMF a raise in his 15yrs of employment ... so that after 15yrs,
the standard starting salary offer for all recent college graduate new
hires ... was now 1/3rd more than what JMF was currently making (after
15yrs of employment).

What would JMF think if he finds out that all the recent college
graduate new hires, that were being brought in to work on a project
that he was technically heading up, were being paid 1/3rd more than
what he was being paid?

Quadibloc <jsavard@ecn.ab.ca> writes:
Unless, of course, the instructions are so complicated that the
microcode for them performs enough elementary operations as to permit
superscalar operation at that level. My point is: in general, if
you've got instructions like "add" and "multiply", and microcode is
handling them, it's hard to make effective use of any ability to add
and multiply at the same time.

no, the individual instruction operations are so simple ... there are
things like start transfer of from register to functional unit. a
single horizontal microcode instruction is controlling possibly
half-dozen or more functional units that are operating in parallel w/o
interlocks.

one of the reasons i mentioned that horizontal microcode was quoted in
avg. number of 370 instructions per machine cycle was that there could
be different operations for multiple 370 instructions going on in
parallel/overlapped ... so they counted the avg. number of 370
instructions that completed in some unit of machine cycles. ref
http://www.garlic.com/~lynn/2007j.html#84 VLIW pre-history

part of the complexity for the horizontal microcoder was that they had
to constantly keep track of which operations were in flight and
approximately how many instructions later could they start the next
operation (i.e. had transfer finished so add operation could be kicked
off, etc).

... i.e. exact opposite from future system in terms of hardware
complexity ... there were (801 related) comments in the 70s like all
operations being fixed single cycle (in part eliminating the type of
complexity and variability that the horizontal microcoders were having
to deal with) and no cache consistency (eliminating the significant
cache consistency overhead/slowdown that was going on in high-end
370s).

VLIW pre-history

Anne & Lynn Wheeler <lynn@garlic.com> writes:
no, the instruction are so simple ... there are things like start
transfer of from register to functional unit. a single horizontal
microcode instruction is controlling possibly half-dozen or more
functional units that are operating in parallel w/o interlocks.

... or more accurately ... the level of control that horizontal
microcode instruction provided was at extremely primitive hardware
component level. the reason that it was referred to as horizontal
microcode was that there was possible control over every primitive
hardware component (in the system) in every instruction (in theory
allowing each single instruction to activate every hardware component
in the infrastructure ... concurrently and in parallel).

Quadibloc <jsavard@ecn.ab.ca> writes:
The meaning of VLIW includes *superscalar*: unless you are
independently executing separate microcode streams for fields in your
source instruction, or generating microcode on the fly - in which
case, it isn't microcode anymore, you have a decoupled
microarchitecture, which _can_ be superscalar - it's pretty hard for a
conventionally microcoded machine to be superscalar.

some of the VLIW implementation have multiple instructions with
multiple op-codes ... encoded in a wide word ... allowing things to be
done in parallel.

this is somewhat similar to mainframes that do i-instruction fetch in
double words or larger units ... fetching multiple instructions in one
operation from storage.

however, an issue in horizontal microcode ... was that it didn't have
instruction op-codes in the sense that most vertical programmers are
familiar. an horizontal microcode instruction had positions for
control of the various low-level/primitive hardware components ... it
could be doing i-fetch, decoding i-fetch opcode, moving stuff to
various execution units, etc ... all in one instruction. basically
lots of the kinds of stuff that current supercaler processors perform
under strictly hardware control ... but left up to the microcoder to
implement in horizontal microcode.