List of Archived Posts

2005 Newsgroup Postings (09/30 - 10/13)

Intel strikes back with a parallel x86 design

Intel strikes back with a parallel x86 design

Intel strikes back with a parallel x86 design

The 8008

OS's with loadable filesystem support?

What ever happened to Tandem and NonStop OS ?

What ever happened to Tandem and NonStop OS ?

DDJ Article on "Secure" Dongle

Intel strikes back with a parallel x86 design

Intel strikes back with a parallel x86 design

Intel strikes back with a parallel x86 design

Intel strikes back with a parallel x86 design

Intel strikes back with a parallel x86 design

Is a Hurricane about to hit IBM ?

Intel strikes back with a parallel x86 design

Intel strikes back with a parallel x86 design

Intel strikes back with a parallel x86 design

Intel strikes back with a parallel x86 design

SATA woes

Intel strikes back with a parallel x86 design

Intel strikes back with a parallel x86 design

z/VM Listserv?

z/VM Listserv?

OS's with loadable filesystem support?

What ever happened to Tandem and NonStop OS ?

PCI audit compliance

VM tape definitions

transactional memory question

Intel strikes back with a parallel x86 design

Job seperators

File path formats

Symbols vs letters as passphrase?

How does the internet really look like ?

The 8008

logical block addressing

X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique

X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique

X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique

IEH/IEB/... names?

What ever happened to Tandem and NonStop OS ?

IEH/IEB/... names?

winscape?

winscape?

Numa-Q Information

What ever happened to Tandem and NonStop OS ?

Password Requirements - VM:Secure

Numa-Q Information

MVCIN instruction

winscape?

MVCIN instruction

winscape?

winscape?

Go-Back-N protocol?

Password Requirements - VM:Secure

NEW USA FFIES Guidance

IBM 3330

Intel strikes back with a parallel x86 design

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch
Date: Fri, 30 Sep 2005 17:37:36 -0600

"Stephen Fuld" writes:

Yes.  Running disk resident was pretty bad in the days of limited
memory as loading segments from disk was awfull.  We wrote code that
copied the segment part of the OS from the boot disk to a dedicated
file on the drum (actually an SSD) so that segments could load from
the high speed device but we didn't ahve to dedicate a whole drum
for it and hassle with the issues of spanning the drum as the exec
grew.

if you had a drum.

as an undergraduate ... I tooked the os/360 stage-ii sysgen punch deck
output and reworked it so 1) run it in a production job stream and 2)
carefully sequence the order of copy/allocate statements controlling
the placement of pieces on the disk.

the univ. had been running student fortran jobs under ibsys on 709
(tape to tape with 1401 for unitrecord<->tape processing).  moving
that to 360/67 (running in 360/65 mode, aka w/o virtual memory) under
os/360 increased the elepased time by nearly 100 times. adding hasp
spooling helped a lot ... however, carefully creation of the
production system (and the resultant optimized arm motion) improved
things another 3 times (from over 30 seconds elapsed time to about 12
seconds). fortran student job processing really didn't return to 709
ibsys monitor thruput until the introduction of watfor.

i gave presentation at the mainframe user group meeting aug68 ...
part of the presentation from an earlier posting
http://www.garlic.com/~lynn/94.html#18 CP/67 & OS MFT14

the above also includes data on running mft14 in virtual machine under
cp67 and the results I got from a couple months of rewritten major
pieces of cp67 kernel (reducing virtual machine kernel processing cpu
time from 534 cpu seconds to 113 cpu seconds ... for running the
fortran student job benchmark under MFT14 in a virtual machine).

360/67 did have a 2301 (fixed head) drum for virtual memory paging
(originally for tss/360 but used by cp/67).

when i shipped the resource manager product ... i had added some
features that would 1) dynamically migrate some fixed real storage
tables to paging devices, 2) dynamically migrate virtual memory pages
both onto and off of fixed-head paging devices (actually generalized
to migrate to/from arbitrary different areas).
http://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager

in the late 70s, I started making assertions about the radical
decline in relative system disk performance.
http://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door

At one point, somebody in the disk division got irritated and assigne
their performance modeling group to refute the statements. after
several weeks, they came back and effectively stated that I had
slightly understated the decline.

one of the issues was that system operations were morphing/evolving to
better take advantage in the large increase in availability of
electronic memory (significant higher use of electronic memory for
things like caching).

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

Intel strikes back with a parallel x86 design

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Fri, 30 Sep 2005 17:53:26 -0600

George Macdonald <fammacd=!SPAM^nothanks@tellurian.com> writes:

You can presume whether I like something or not; that was a minor time
slice in the PC evolution.  It did not take long for even IBM to get the
msg that a 327x was not going to hack it for the "user experience" in the
brave new world of spreadsheets, word processing and... graphics, which IBM
did not even make a PC card/monitor for to begin with.

however, one of the reasons behind big uptake of ibm/pcs ... was that
businesses could get a single machine (ibm/pc) for about the same
price as 327x ... and it could provide both 327x terminal and also
capability of doing some amount of local processing on the desk ...
as well as it had footprint of single display & keyboard (didn't
require two screens and two keyboards for each desk in order to have
both mainframe dataprocessing access and also local desktop stuff).
http://www.garlic.com/~lynn/subnetwork.html#emulation

the big uptake created quite a large install base of terminal
emulation products ... which was being threatened as PCs evolved into
more advanced computing capability ... as well as client/server was
raising its ugly head. this sort of gave rise to SAA ... which
nominally claimed that it was going to make it transparent where
something actually executed (PC or mainframe) ... but there was a lot
of effort in SAA going on to port major PC applications to the
mainframe ... and use the PC purely as sophisticated display devices.

In this period, my wife had co-authored and presented a corporate
response to a large federal request for secure, campus-like distribute
envrionment ... where she had formulated a lot of the pieces of 3-tier
architecture. we then expanded on that and were making 3-tier and
middle layer customer executive presentation ... which didn't endear
us to any of the SAA proponents. recent posting going into more
detail
http://www.garlic.com/~lynn/2005q.html#18 Ethernet, Aloha and CSMA/CD
http://www.garlic.com/~lynn/2005q.html#19 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem and NonStop OS?

some number of collected postings referencing 3-tier architecture
http://www.garlic.com/~lynn/subnetwork.html#3tier

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

Intel strikes back with a parallel x86 design

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Fri, 30 Sep 2005 18:34:41 -0600

archmage@sfchat.org (Nate Edel) writes:

Rackmount, no, but I saw quite a number of places using first generation
PS/2 386 systems as file servers or as the server for POS applications
around 1989-1990 or so.  I never saw a rackmount *anything* until about
1993.

I think they were called industrial PCs and possibly started with XTs
(or maybe even original PCs) ... we had some number of rackmount
PC/ATs with mainframe channel attach cards (PCCA). PCCA showed up
spring 85 ... in configurations with PC/Net LAN cards.

A flavor of this evolved into 8232 ... the mainframe controller
tcp/ip; industrial pc/at and a mainframe channel interface card with
8232 nameplate (big hairy bus&tag tailgate interface).

there was some issues with how the 8232 TCP/IP support was actually
implemented ... and as a result the mainframe side processor could
burn 100 percent of one 3090 processor getting 44kbytes/sec. I then
added RFC1044 support to mainframe tcp/ip was in some tuning at cray
research ... between a 4341-clone and a cray was getting mbyte/sec
(4341 channel media thruput) using only a small amount of the 4341
(aka about 25 times more bits for maybe 1/100th the cpu
processing). misc.  past rfc 1044 posts
http://www.garlic.com/~lynn/subnetwork.html#1044

at the time there was some rumors and folklore about project that
integrated some tcp/ip support into the standard SNA processing
environment (vtam, 37xx, etc) where they had hired an outside
contractor for the effort. Supposedly the first cut had tcp/ip running
with significantly higher thruput than LU6.2 thru the same
infrastrucutre.  supposedly it was sent back as flawed and having to
be redone (at least until tcp/ip was no longer faster than LU6.2).

the industrial pc/at with PCCA had also started out with significantly
higher thruput than what was finally shipped in the 8232 support.

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

The 8008

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The 8008
Newsgroups: alt.folklore.computers
Date: Fri, 30 Sep 2005 20:39:42 -0600

jmfbahciv writes:

When we cruised into the harbor for Shanghai,
(the year the first shuttle blew up) the smell
reminded me vividly of Gary, Indiana when I was a child.
All the middle-class snobs on board denigrated China
about being so "dirty".  These people had forgotten what
life was like before the 1960s in the US.  What will
be interesting is if China will skip the problems caused
by automobiles; it doesn't appear so.  A lot of third world
countries have been skipping the copper wire technology
for communications and going straight to cellaphony(sp?).

we have letters from my wife's mother to her mother describing the
family's trip leaving san fran, stopping hawaii, japan and arriving in
shanghai ... but a couple decades earlier.  they were in nanking for a
couple years until being airlifted out of the city in a army cargo
plane on 3hrs notice. they arrived in tsing tao after dark ...  with
the airfield lit by headlights from motor vehicles. the letters
comment on the strong smell of honeypot fertilizer that was everywhere
(extensively used all over the far east).

previous referenece
http://www.garlic.com/~lynn/2004e.html#19 Message To America's Students: The War, The Draft, Your Future

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

OS's with loadable filesystem support?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OS's with loadable filesystem support?
Newsgroups: alt.folklore.computers
Date: Fri, 30 Sep 2005 20:55:43 -0600

"bob7094" <bob dot 7094 at comcast dot net> writes:

Further correction - the application accessed logical unit numbers assigned
by the user, not filenames, not unlike OS 360.

slightly related post on issues of disk use in os/360
http://www.garlic.com/~lynn/2005r.html#0 Intel strikes back with a parallel x86 design

however, one of the other things that i did to cp67 was add tty/ascii
support. i thot i could do some really fancy stuff with 2702 terminal
controller ... dynamic terminal and line speed recognition. I was able
to do the dynamic terminal stuff with 2702 (being able to dynamically
reassign line-scanner to different ports) ... but the 2702 wasn't
capable of handling dynamic line speed ... line speed oscillator was
hardwired to each port.

this spawned a university project to build our own controller
... reverse engineering the 360 channel interface and building a
controller channel board that went into an interdata/3 programmed to
emulate a mainframe controller (AND do dynamic line speed operation).

somewhere there is a article supposedly blaming four of us at the
university for spawning the mainframe plug compatible controller
business
http://www.garlic.com/~lynn/subtopic.html#360pcm

and supposedly the plug compatible controller business was the
big driving factor behind FS (which was a really large project
but was canceled before ever being announced)
http://www.garlic.com/~lynn/submain.html#futuresys

and I've frequently commented that the origins of 801/risc was
attempting to do nearly the exact opposite of the horribly
complex FS effort
http://www.garlic.com/~lynn/subtopic.html#801

a few years ago I ran into somebody who said that he had made a really
good living selling perkin-elmer machines into fed. gov. accounts in
the early 80s, (where they attached to mainframes) ... and after some
discussion, he commented that channel attack board looked like it
hadn't been redesigned since the original one that we built in the 60s
(aka ... perkin-elmer had bought interdata and was selling the boxes
under their logo).

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

What ever happened to Tandem and NonStop OS ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Fri, 30 Sep 2005 22:55:05 -0600

"Rupert Pigott" writes:

"So is 'Microsoft Shared Source' a failed attempt at Open Source? Not
really. In fact it is a demonstration of how far Microsoft are from
grasping the entire concept of Open Source. IBM were providing source
code in the 1960's under similar terms. VMS source code was available
under limited licenses to customers from the beginning. Microsoft are
catching up with 1960."

cp67 shipped source code maintenance. the 6/23/69 unbundling
accouncement started charging/licensing application software
... however kernel software was still free (under the theory it was
required for the hardware). mainstream batch systems shipped
executable maint. and source was available on fiche.

however cp67 morphed into vm/370 and continued to ship source code
maint. monthly PLC (program level change) maint. tapes had both
complete system executable build ... as well as all the source for for
rebuilding system from scratch. the multi-level source code update
infrastructure was part of this ... the stuff on the monthly PLC tapes
were the base release source ... plus all the individual, incremental
source code updates that had been created since the release.

many customers had extensive updates of their own ... and monthly PLC
maint. frequently required merging the local customer source updates
with the new product updates ... and/or retrofitting specifically
selective product maint. updates to customer source built system.

some amount of features that I had implemented as an undergraduate for
cp67 got dropped in the morph from cp67 to vm370 ... however there
were numerous customers lobbying for them to be made available in the
vm370 product. eventually i got to do the resource manager for
vm370 ... posting of the old original product announcement letter
http://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager

some number of other references to pieces of the resource manager
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

however they also selected the resource manager to be guinea pig
for charging for kernel software
http://www.garlic.com/~lynn/submain.html#unbundle

which met that I had to spend quite a bit of time with the business,
legal, and pricing people on creating policy for kernel software
pricing. that iteration of kernel software charging was that new
kernel code not directly required for hardware support could be
charged for (while direct hardware support software like device
drivers were still free). this policty created kernel software
features ... base (free) product with selected purchased add-ons.
This lasted a couple of years ... and eventually they reintegrated and
charged for a single kernel which they renamed VM/SP (i.e. system
product).

there was something of a hiccup with the resource manager tho. In the
initial resource manager i included a whole lot of kernel rewrite ...
and when they decided to ship SMP support in the following release ...
it was realized that a lot of stuff that SMP support required I had
already shipped in the resource manager. This created a policy problem
since it would be a violation to have as a prerequisite for the *free*
SMP support, the priced resource manager.

the problem was that I had done the overall SMP design .. predicated
on a bunch of kernel structural changes that I had included with the
resource manager. the eventual resolution was to move possibly 80
percent of the resource manager code into the free kernel. misc.
past smp posts
http://www.garlic.com/~lynn/subtopic.html#smp

note ... even tho the resource manager was charged for ... it still
shipped as source code maintenance ... and in fact was a set of source
code updates to the base, free kernel code. source code
maint. continued even after move to pricing for all kernel code with
vm/sp. however OCO (object code only) was being strongly pushed
... putting it even footing with the other operating systems. OCO
was heavily debated issue at customer user group meetings and
on vmshare ... especially hot item during the mid-80s.

vmshare archives
http://vm.marist.edu/~vmshare/

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

What ever happened to Tandem and NonStop OS ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Fri, 30 Sep 2005 23:04:24 -0600

oh, ref
http://www.garlic.com/~lynn/2005r.html#5 What ever happened to Tandem and NonStop OS?

... and misc. past posts mentioning multi-level source update stuff
http://www.garlic.com/~lynn/2002n.html#39 CMS update
http://www.garlic.com/~lynn/2003.html#62 Card Columns
http://www.garlic.com/~lynn/2003e.html#66 History of project maintenance tools -- what and when?
http://www.garlic.com/~lynn/2003f.html#1 History of project maintenance tools -- what and when?
http://www.garlic.com/~lynn/2003j.html#14 A Dark Day
http://www.garlic.com/~lynn/2004b.html#59 A POX on you, Dennis Ritchie!!!
http://www.garlic.com/~lynn/2004g.html#43 Sequence Numbbers in Location 73-80
http://www.garlic.com/~lynn/2004m.html#30 Shipwrecks
http://www.garlic.com/~lynn/2005b.html#61 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005c.html#42 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005i.html#30 Status of Software Reuse?
http://www.garlic.com/~lynn/2005i.html#39 Behavior in undefined areas?
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3

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

DDJ Article on "Secure" Dongle

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: DDJ Article on "Secure" Dongle
Newsgroups: sci.crypt
Date: Sat, 01 Oct 2005 08:39:52 -0600

"TC" writes:

Piracy is a legitimate concern for software authors.

My experience, with my own product, is that 1% of effort will deter 99%
of people who would otherwise pirate my app. But we all know that no
amount of extra effort will deter the remaining 1%.

So, dongles etc. al. are just a waste of time and money. The people who
are deterred by those, would be equally deterred by an encrypted value
in the registry, or somesuch simple scheme.

it may be the reverse of swimming pools and fences ... if you have a
fence ... it isn't your fault ... if you don't have a fence then it is
your fault. demonstratable countermeasures ... are enuf to take
action ... either by employers to fire employees that violate. if you
are charging ... and some large corporation is in flagrant violation
action can be taken. one percent not paying/stealing can be tolerated
... i think a lot of companies figure that they are going to have 5-7
precent loss ... places like retail stores ... employees mostly ...
but also straight-forward customers shoplifting. sometimes the counter
measures are both simple deterrent for most, as well as basis for
various kinds of legal action.

there was a trade-secret theft situation ... where legal action was
brought claiming several billion damages ... the judge invoked the
swimming pool scenario; if it really is billions of dollars ... some
large fraction of the population will be expected to steal, as a
matter of course, and you can't really hold it against them ... unless
you show that you have taken countermeasures proportional to the value
of what is being protected. if isn't absolute ... and the
countermeasures wouldn't be expected to cost more than value of what
is being protected ... just demonstratable proportional.

that was possibly one of the places i picked up security proportional
to risk ... some slight topic drift
http://www.garlic.com/~lynn/2001h.html#61 Security Proportional To Risk

in any case, given swimming pool scenario and judges wanting to see
countermeasures proportional to value ... then the issue may be the
value of the software and how much are you charging for each license.

and then there is some additional topic drift ... straying back to
unbundling announcement on 6/23/69 and starting to charge for
application software ... although kernel software was still free.
however, when i was doing the resource manager ... it got selected to
be the guinea pig for first charged for kernel software ... and i got
to spend lots of time with business and legal people on software
pricing policies. some past collected posts on unbundling and software
pricing
http://www.garlic.com/~lynn/submain.html#unbundle

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

Intel strikes back with a parallel x86 design

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Sat, 01 Oct 2005 10:23:36 -0600

keith writes:

While I agree with your sentement, there wasn't any lack of a
graphics card.  The CGA card and monitor were announced and shipped
with the 5150.  I had a CGA card (couldn't afford the monitor) on my
"first day order" 5150.  ...along with the monochrome card and
monitor.

OTOH, contrary to Nick's point, the 5150s did not ship with a 3270
emulator card.  Those came later (IIRC IBM wasn't even first), as it
became obvious the PC was a better and cheaper 3270.  Saying that
the The PC was originally intended to be a 3270 replacement is "new
history", at best.

I had first day employee order ... the day before it arrived, the
prices were lowered ... and I could pick up same configuration at
computerland for less than i had paid in the employee order.

the PC wasn't originally intended to be 3270 replacement ... but it
(eventually) got big boost in market penetration when it started being
used for terminal emulation. in fact, before mac was announced ... I
even had arguments with some of the mac developers about its chances
of success w/o some commercial support ... like terminal emulation (my
brother was regional apple marketing rep ... he claimed he had the
largest physical territory in continental US ... anyway when he came
into town, we had dinners with various people).

in any case, terminal emulation in turn, resulted in large install
base of equipment around the terminal emulation business. then with a
large terminal emulation install base ... it had to be protected. the
growing capability and emerging client/server paradigm was a threat to
this install base.  SAA supposedly was that applications could be run
everywhere ... but there was a lot of money being spent on porting PC
applications to the mainframe ... hoping to stuff the client/server
genie back into the bottle.
http://www.garlic.com/~lynn/subnetwork.html#emulation

in this period ... we had come up with 3-tier architecture, middle
layer, etc and were out pitching it in customer executive presentation
... which didn't endear us to any in the SAA crowd (and since it was
also ethernet oriented ... didn't make any friends with the t/r
people). In previous life, I had worked frequently with the person
responsible for SAA ... so we would periodically stop by his big
corner office in somers (some joke he could almost see endicott from
it) and give him a bad time about the reality of SAA prospects.
http://www.garlic.com/~lynn/subnetwork.html#3tier

one of the threats to the terminal emulation business was the
increasing number of business applications showing up on PCs ... this
in turn was driving big business for PC hard disk capacities ... and
you started seeing a noticeable decline in the growth of mainframe
disk sales as business data leaked into the distributed
environment. the disk division came up with several products that
would provide extremely high-thruput disk access to glass house data
by PCs and other distributed processes ... with lots of business case
justification like data backup, integrity, disaster/recovery, etc
(they even had statistics on businesses that declared bankruptcy when
unbacked up data on PC disks was lost).

In any case, this resulted in significant wars between the disk
division and the division responsible for terminal emulation business
... with the division responsible for terminal emulation business
claiming total strategic responsibility for everything outside the
walls of the mainframe machine room.  One of the disk division's
retaliations was giving a presentation at a large internal conference
going into gory detail about how the communication division was going
to be directly responsible for the demise of the mainframe disk
division (the limited terminal emulation spigot was greatly
accelerating the migration of data residency out into the distributed
environment)

as an aside ... there was a acorn software project out on the west
coast; boca had said it wasn't doing or involved in software ... and
it was perfectly reasonable for the west coast group to do software.
possibly monthly, boca was contacted to reaffirm that they weren't
interested in software and west coast was free to take on software
mission. then at some point, boca changed its mind and effectively
said that the west coast group couldn't do the software mission ..
and if the people involved wanted to be involved in software mission
for acorn ... they had to move to boca.

some past posts mentioning acorn
http://www.garlic.com/~lynn/2002g.html#79 Coulda, Woulda, Shoudda moments?
http://www.garlic.com/~lynn/2003c.html#31 diffence between itanium and alpha
http://www.garlic.com/~lynn/2003d.html#9 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003d.html#19 PC history, was PDP10 and RISC
http://www.garlic.com/~lynn/2003e.html#16 unix
http://www.garlic.com/~lynn/2005q.html#24 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem and NonStop OS ?

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

Intel strikes back with a parallel x86 design

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Sat, 01 Oct 2005 12:43:45 -0600

ref:
http://www.garlic.com/~lynn/2005r.html#8 Intel strikes back with a parallel x86 design

oops, unbundle was brain-check ... attention momentarily wandered to a
posting doing in parallel concerning free software from the 60s and
the transition to priced software in the 70s ... aka
http://www.garlic.com/~lynn/2005r.html#7 DDJ Article on "Secure" Dongle
i.e.
http://www.garlic.com/~lynn/submain.html#unbundle

it should have been reference to collection of postings on
terminal emulation
http://www.garlic.com/~lynn/subnetwork.html#emulation

note that 20 years ago ... the disk division was starting to come up
with these mainframe nas/san like solutions for the distributed
environment ... and the communication division was constantly killing
the efforts ... protecting their position as owning everything that
crossed the wall of the mainframe machine room.

it also gave my wife fits earlier when she was con'ed into going to
pok to be in charge of loosely-coupled architecture. stuff that she
could potentially do between mainframes in the same machine room
couldn't be done when it was between the same mainframes but in
different machine rooms (because it then became the responsibility of
the communication division). it is possibly also why the mainframe
fiber-optic interconnect languished in pok for a decade ... the
mainframes machine rooms had to get big enuf and complex enuf to
justify fiber intra-room interconnect ... and (a very) few battles had
to be won with the communication division to allow some to cross the
boundary of the machine room wall (to be used for inter-room
interconnect).

when i was doing high-speed interconnect project ... i purposely
called it HSDT (high-speed data transport)
http://www.garlic.com/~lynn/subnetwork.html#hsdt

to try and help differentiate it from communication (and the
responsibility of the communication division). something that sort of
highlighted the difference ... I was about to leave on a trip to the
far east to contract for some equipment. the friday before i left,
somebody from the communication division announced a new discussion
group on "high-speed" ... and offered the follow definitions for use
in the discussions

  low-speed               <9.6kbits
  medium-speed            19.2kbits
  high-speed              56kbits
  very high-speed         1.5mbits

monday morning in a conference room outside of Tokyo were these
definitions on the wall:

  low-speed               <20mbits
  medium-speed            100mbits
  high-speed              200-300mbits
  very high-speed         >600mbits

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

Intel strikes back with a parallel x86 design

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Sat, 01 Oct 2005 13:36:39 -0600

for some additional drift from terminal emulation
http://www.garlic.com/~lynn/2005r.html#6 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#6 Intel strikes back with a parallel x86 design

to nas/san ...  in the mid-80s both LANL and NCAR (boulder) were doing
things where standard ibm mainframe was handling tape library and disk
farm for a variety of supercomputers on the same machine room
floor. they used HYPERchannel for both processor (messaging)
interconnect and processor/device (I/O) interconnect.

ncar would possibly have a cray make a request to ibm mainframe for
some data. the mainframe would possibly stage it from tape to disk (if
necessary) and then initialize the appropriate HYPERChannel remote
device adapter (it emulated an ibm channel) that the particular disk
controller was attached to. a coding sequence was then returned by the
ibm mainframe to the cray (HYPERChannel message). The Cray would then
signal the indicated HYPERChannel remote device adapter with the
correct coding sequence ... to do the actual (direct) data transfer.

LANL was in large part behind the IEEE standardization work for cray
channel as HiPPI. There was some effort in both IPI3 (disk) standards
activity and HiPPI switch standardization ... to make sure that
third-party transfers (of the kind NCAR was doing with the
HYPERchannel remote device adapter) were supported.

I got asked advice on some of this because in the early 80s, I had
done some mainframe device driver work for HYPERChannel.

A specific situation in the early 80s was that the Santa Tersa Lab was
overflowing and there was a decision to move 300 IMS (database)
programmers off-site ... but with remote access to the machine room.
Remote 3270s were evaluated (max at 9600 baud operation) and quickly
discarded. So the solution was to create high-speed connection between
STL(bldg.90) and the new offsite location ten miles away
(bldg. 96/97). HYPERChannel was to be used for channel extension with
300 "local" 3270s (and other devices) at the remote site. It was
possible to scavange some bandwidth from the "campus" T3 collins
digital radio ... aka bldg. 12 on the main plant site had digital
radio to the repeater tower on the hill above STL ... and also
line-of-sight to the roof of the new off-site bldg. It just required
hooking up the appropriate circuits ... and making sure they had
point-to-point link encryptors.

Folklore is that when hiway 85 elevated section was first
opened... cars had their radar detectors trip when crossing the path
between bldg.12 and the STL repeater tower ... approx. here:
http://www.mapquest.com/maps/map.adp?country=US&addtohistory=&formtype=address&searchtype=address&cat=&address=State%20Hwy%2085%20%26%20Via%20Del%20Oro&city=San%20Jose&state=CA&zipcode=95119&searchtab=home

link encryptors were used on everything ... at one point in the
mid-80s, there was a claim that internal operations had well over half
of all link encryptors in the world (and all the orders established at
least one company in the crypto business).

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

Intel strikes back with a parallel x86 design

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Sun, 02 Oct 2005 10:29:48 -0600

George Macdonald <fammacd=!SPAM^nothanks@tellurian.com> writes:

The bottom line, which I was trying to get across, is that in a
software system which exercised the CPU across all its spectrum of
operations, the 68K was a dog.  It was just as much a dog at pure
"commercial" work as it was at quasi-scientific "business"
application work - the CPU was just slow in general and saddled with
an idealistic orthogonal ISA.  The 386 was simply a better performer
and the PowerPC was never going to better enough.

byte article from 11/96 ... a little later in time
http://www.byte.com/art/9611/sec6/art13.htm

PowerPC Regroups

Stung by Intel's gains in processor performance, the PowerPC alliance
will strike back with higher clock speeds and new chip designs.

Don't count your megahertz before they're hatched. That's what the
PowerPC alliance has learned after prematurely gloating over the
imagined obsolescence of Intel's x86.

One famous advertisement from 1992 showed how CISC performance was
falling flat while RISC technology soared toward the SPECint
stratosphere. Another ad warned about the coming fate of x86-based PCs
by picturing a highway running smack into a brick wall.

... snip ...

and a little earlier also from byte
http://www.byte.com/art/9411/sec8/art5.htm

PowerPC 620 Soars

Its faster logic, shorter pipelines, and high-speed interface endow it
with processing power that raises it to workstation and server caliber

... snip ...

and a little discussion of power and power/pc
http://www.research.ibm.com/journal/rd/385/preface.html

During the four years since the RISC System/6000* (RS/6000)
announcement in February of 1990, IBM* has strengthened its product
line with microprocessor enhancements, increased memory capacity,
improved graphics, greatly expanded I/O adapters, and new AIX* and
compiler releases. In 1991, IBM began planning for future RS/6000
systems that would span the range from small, battery-operated
products to very large supercomputers and mainframes. As the first
step toward achieving this "palmtop to teraFLOPS" goal with a single
architecture, IBM investigated further optimizations for the original
POWER Architecture*. This effort led to the creation of the PowerPC*
alliance (IBM Corporation, Motorola*, Inc., and Apple* Computer
Corporation) and the definition of the PowerPC Architecture*.

.. snip ..

power was rios ... was a traditional 801/risc architecture ... no
cache consistency, no provision for SMP, some number of hardware
trade-offs issues from the original idea from the 70s. however, the
demise of various proprietary efforts in the early 80s ... and the
romp displaywriter followon ... had it stray from proprietary into the
world of unix and (more) open systems. i was assured at an advanced
technology conference in the mid-70s that the use of 16 segment
registers for virtual memory support ... was a hardware simplicity
trade-off ... aka a lot of 801 was swinging the pendelum to the
opposite extreme in reaction to the extremely complex FS (which was
eventually killed w/o being announced):
http://www.garlic.com/~lynn/submain.html#futuresys

... in any case, the claim at the time ... was the combination of no
protection domain and ability of inline application code could change
(virtual memory) segment register values (as easily as general
register address pointers could be changed) would more than compensate
for the limited number of segments (for various memory mapped paradigm
implementation).
http://www.garlic.com/~lynn/subtopic.html#801

in some sense ... somerset and powerpc was going after both larger
volume market ... as well as migrating to somewhat more traditional
processor architecture with support for cache consistency,
multiprocessor operation, etc.

at the time, the executive we directly reported to in the hardware
group when we were doing ha/cmp ... misc ha/cmp refs (note none of the
executives mentioned in the following post is anybody we directly
reported to):
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/subtopic.html#hacmp

had previously worked for motorola. with the formation of somerset, he
moved over to head up somerset and the powerpc effort.

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

Intel strikes back with a parallel x86 design

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Sun, 02 Oct 2005 12:34:06 -0600

"Stephen Fuld" writes:

But the TSO editor was there, and clearly intended for program
development

there are lots of jokes among customers about TSO being too slow to
use for interactive (even some recent threads in ibm-mainframe group).
basically TSO was slightly better than using a keypunch.

when we were arguing with product group about being able to have
subsecond response with the new 3274 display control units ...
effectively TSO came down on the side of the 3274 group ... since they
never had subsecond response ... even with the faster 3272 controller.
Basically 3274 group defined their target market (what is cause and
what is effect?) as data entry (previously done on keypunches) which
don't have any issues with system performance and response.

reference to old report with numbers comparing 3277 & 3274:
http://www.garlic.com/~lynn/2001m.html#19 3270 protocol

from above:

               hardware     TSO 1sec.    CMS .25sec.     CMS .11sec
3272/3277        .086        1.086         .336            .196
3274/3278        .530        1.530         .78             .64

...

as mentioned in the above reference the numbers are very idealistic,
optimistic numbers for TSO (talk to customers that complained about
several seconds being more typical) ... and normal range of measured
numbers for production CMS environments. The joke in the above was
that .25sec was nominal for most CMS operations ... but the .11sec was
typical of several places running my latest performance tweaks (at the
particular point in time that the 3274/3278 issue was being debated).

also the hardware numbers are for direct channel attached controllers;
SNA managed controllers had significantly worse hardware response
(even local SNA controllers ... but remote SNA controllers were the
pits)

there was passing reference to subject in previous post
http://www.garlic.com/~lynn/2005r.html#10 Intel strikes back with a parallel x86 design

where the IMS development group being remoted off-site couldn't face
the prospect of using remote 3270s ... even in conjunction with their
normal development environment (aka most of the machines at STL ...
which housed IMS, DB2, PLI, APL, Pascal, and number of other
development groups ... were vm370/cms).

Part of the issue in the 3272/3274 was that the 3274 had moved some
amount of the electronics & logic out of the 327x terminal head ...
back into shared controller logic (reducing 327x terminal
manufacturing costs but contributing to performance issues).

For some of us ... even local channel, "fast" 3272/3277 had some
issues ... while the controller operated at 640kbytes/sec ... there
were still some half-duplex latency issues. A little soldering in the
keyboard and additional electronic modification in the display head
... took care of some of the issues.

In spring of '85, a mainframe channel interface card was produced for
PC/AT (16bit isa bus) that was configured with pc/at with PCNET lan
cards and some changes for psuedo 327x terminal operation.  emulator
was then written for PCs on the PCNET lan ... that was loosely
3270-like ... as well as some enhanced controller support software on
vm370 mainframe. since it was internal operation ...  various
liberties were taken with all of these to eliminate as many annoying
characteristics as possible.

This was quickly replaced with enet lan cards. About a decade later
and the technology was finally starting to best the turbo-charged 3277
environment.

In the 70s, an internal 3270 telnet-like server/demon terminal
emulation package had been developed for vm370. it included support of
program interface to application running in local cms virtual machine.
programmatic scripting language quicly evolved for this interface
... with a lot of features that would later appear in HLLAPI support
(pc application doing 327x screen scraping). the most prevalent
internal was the parasite/story package done in the UK ... past
parasite/story posting
http://www.garlic.com/~lynn/2001k.html#35 Newbie TOPS-10 7.03 question

note that the REXX author had used some of the same basic technology
for implementing a multi-user spacewar game (that supporting
time-sharing users on local machines and/or remote users over network
links).

Then my home 300baud/ti700 was upgraded to 1200buad/3101. 3101 was
basically glass teletype ... but had something called "block mode".
You could either dial into the system as glass teletype ... or you
could connect directly to the 3270 server/demon and have it drive the
terminal in block-mode. The internal 3270 server/demon had been
upgraded to directly drive 3101 block mode and use its features to
optimize the terminal operation.

When I got my employee purchase ibm/pc ... minor previous reference
http://www.garlic.com/~lynn/2005r.html#8 Intel strikes back with a parallel x86 design

i was able to replace the 300baud/3101 setup with 1200baud/ibmpc
terminal emulation. a greatly enahced package was developed for the
ibm/pc that also interacted with a whole bunch of new features in the
3270 server/demon (available when it was directly driving the
line). fundamental was sophisticated transmission compression as well
as dictionary of common stuff and cache of already transmitted stuff
(the host server/demon kept state about what was in the pc cache ...
and instead of of doing compressed transmission ... it had control
features to display stuff from the cache).

it was this basic technology infrastructure (3270 server/demon) that
then had enhancements to drive the channel-attached PC/AT LAN gateway
for local terminal emulation.

,,, some topic-drift ... the home terminal program initially developed
a dial-in interface that supported callback (aka you dialed,
identified yourself ... and the interface then hung up and called back
the number listed for the identification). this was enhanced with a
encrypting 2400baud hayes-compatible async card ... that did a sort of
SSL session hand-shake (not using public key tho), establiehed session
key and then ran encrypted session. this was then required for all
home terminals and people using portable terminals/laptops dialing in
from hotels (a detailed vulnerability study had turned up hotel PBXs
as being one of the most likely compromised points in the
infrastructure).

folklore has it that one of the early prototype crypto asyncr cards
wad provided to a senior executive. he had been an old time EE ... and
during testing touched his tongue to the contacts in the phone jack
... just as the phone rang. after that it was mandated that all async
cards built by the corporation had to have recessed jack contacts (so
innocent individuals, like corporate senior executives, couldn't touch
them with their tongue).

various past other posts discussing issues using HYPERChannel for
mainframe channel extension (used for moving 300 from the ims group to
off-site location but allowing them retain their "local" 3270s).
http://www.garlic.com/~lynn/94.html#23 CP spooling & programming technology
http://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000f.html#30 OT?
http://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems.  Disk history...people forget
http://www.garlic.com/~lynn/2001g.html#33 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001g.html#34 Did AT&T offer Unix to Digital Equipment in the 70s?
http://www.garlic.com/~lynn/2001k.html#46 3270 protocol
http://www.garlic.com/~lynn/2001n.html#3 News IBM loses supercomputer crown
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
http://www.garlic.com/~lynn/2002j.html#74 Itanium2 power limited?
http://www.garlic.com/~lynn/2003g.html#22 303x, idals, dat, disk head settle, and other rambling folklore
http://www.garlic.com/~lynn/2003h.html#15 Mainframe Tape Drive Usage Metrics
http://www.garlic.com/~lynn/2003k.html#22 What is timesharing, anyway?
http://www.garlic.com/~lynn/2005e.html#13 Device and channel
http://www.garlic.com/~lynn/2005e.html#21 He Who Thought He Knew Something About DASD
http://www.garlic.com/~lynn/2005r.html#10 Intel strikes back with a parallel x86 design

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

Is a Hurricane about to hit IBM ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Is a Hurricane about to hit IBM ?
Date: Sun, 02 Oct 2005 12:57:21 -0600
Newsgroups: bit.listserv.ibm-main

AntonMvs2005 wrote:

Most of us could be seen as "Sitting in a dark room reading IBM
manuals for a living", or that's what I have been doing for most of my
life but I am trying to think a little "wider".

So, you might say where are you going with this ?

Anybody remembers where JES comes from ...

how many people know where the spring '68 SHARE meeting was held? How
many attended? Did you get to have a tour of the local large installation?

for some slight topic drift ... some posts x-posted to comp.arch,
intel, & ibm/pc hardware newsgroups ... strays into terminal
emulation and the point behind SAA?
http://www.garlic.com/~lynn/2005q.html#25 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#31 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#33 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#35 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#36 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#38 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#40 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#42 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#43 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#44 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#45 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#46 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#47 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005q.html#48 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#0 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#1 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#2 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#8 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#9 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#10 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#11 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design

Intel strikes back with a parallel x86 design

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Sun, 02 Oct 2005 13:34:33 -0600

keith writes:

We had second(ish) *trivial* response when we were co-located with the
hardware.  With a block editor this wasn't too bad (sure beat 2741s on
acoustic couplers). In Bldg, 701 such performance was rather tough to do
since the systems were all in SRL (about five miles away) and there were
three heads per 9600bps modems. :-(

that is one reason why when 300 people from the ims group were moved
to an off-site location ... they refused to go with remote 3270s; they
had a hard time tolerating any of the "local" SNA &/or MVS flavors ...
just give them local channel attach 3270s to cms (1980s time-frame).

there was some 2nd order effects that actually resulted in moving the
local 3274s for 300 people offsite ... using HYPERCHannel for channel
extension over microwave link ... actually improved performance.

while we are talking about channel-attach *local* 3274s ... there were
a number of performance issues with the 3274s. One was that they had
very high I/O command processing overhead ... which significantly
increased channel busy time (even when we are talking about channel
data transfer rates of 640kbyte/sec for 3274 controllers).

At the time, the STL machines were configured with 16 channels ...
and had large number of disks and 3274 controllers intermixed on
(almost) all channels.

The HYPERChannel configuration involved moving the *local* channel
attach 3274 to remote site ... and connecting them to HYPERChannel
A510 remote device adapters (A510s emulated ibm mainframe
channels). Then HYPERChannel A220 device adapters were attached
directly to the IBM channel .... and the HYPERChannel transport layer
handled the connection between the local A220 channel attach box and
the remote A510 ibm channel emulation box. It turns out that the A220
was a much faster box than the 3274 and resulted in significantly
lower channel busy time doing the same exact operations (vis-a-vis
configuration with 3274s physically attached directly to IBM
channels).

The reduced channel busy resulted in better disk i/o thruput and an
overall system thruput improvement of 15-20 percent. The overall
system thrput improvement contributed to also improvement of trivial
interactive response ... which more than offset any increase in
latency involving HYPERChannel and microwave links.

When my wife had been con'ed into going to POK to be in charge of
loosely-coupled architecture ... misc. references
http://www.garlic.com/~lynn/submain.html#shareddata

... one of the groups she worked with was the POK interconnect group
... which primarily was doing CTCA and then 3088 ... but had hopes of
some day of getting fiber-optic interconnect out the door (which they
eventually were able to did as escon). To some extent, the POK
interconnect group and my wife fought the same battles with SNA
organization ... over being forced to revert to SNA operation anytime
they crossed the machine room wall boundary.

However, when it came time to try and get my HYPERChannel device
drivers released as IBM products ... not only were there loud howls of
objection from the SNA organization ... but the POK interconnect group
came down on the side of the SNA organization. In this scenario they
were still harboring hopes that they could prevail over the SNA
organization and get out their high-speed fiber optic interconnect
... and have it available crossing the machine room boundary.  The POK
interconnect group felt that the HYPERChannel interconnect was
(potentiallY) as much a longterm threat to their objectives as it was
a threat to the SNA organization's products (so it was time to circle
the wagons, forget for the moment their differences and oppose the
common enemy).

.. a little history ... Cray and Thorton worked together at CDC; Cray
left to found Cray Research to build supercomputers, Thorton left to
do high-speed heterogeneous i/o interconnect and founded Network
Systems ... which produced HYPERChannel. More recently, NSC was
acquired by STK ... which just recently was acquired by SUN.

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

Intel strikes back with a parallel x86 design

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Sun, 02 Oct 2005 13:56:43 -0600

Anne & Lynn Wheeler writes:

reference to old report with numbers comparing 3277 & 3274:
http://www.garlic.com/~lynn/2001m.html#19 3270 protocol

from above:

                hardware     TSO 1sec.    CMS .25sec.     CMS .11sec
3272/3277        .086        1.086         .336            .196
3274/3278        .530        1.530         .78             .64

...

as an aside ... the 3722 hardware response was relatively uniform ..
while the 3274 hardware response was data sensitive ... the .53 value
was somewhat a nominal best case; the TSO 1sec was a hypothetical
avg., and the .25sec was measured avg. across large number of actual
operations ... note however, for the .11sec live system, long term
number ... it wasn't avg. ... it was 90th percentile (avg. was
actually less).

one of the (other human factors) problems with the 3274 was (keys &)
typamatic was implemented in the controller ... with fixed value (that
was one of the things that got moved out of the 3277 and back to the
controller to cut down on terminal manufacturing costs).

one of the turbo things we could do with the 3277 ... was a little
soldering inside the keyboard and choose your own typamatic delay &
rate values. We had a number of keyboards done at .1 & .1. However,
the .1 typamatic rate was faster than the screen refresh rate ...
holding down a cursor movement key would develop a time-delay lag on
the screen ... and then the cursor would appear to coast for some
period of time after you took you finger off the key. It took a litte
bit of getting use to ... in order to have a cursor stop at the exact
screen position (since the display feedback was lagging behind how
long you held the key down).

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

Intel strikes back with a parallel x86 design

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Sun, 02 Oct 2005 14:19:08 -0600

Anne & Lynn Wheeler writes:

However, when it came time to try and get my HYPERChannel device
drivers released as IBM products ... not only were there loud howls of
objection from the SNA organization ... but the POK interconnect group
came down on the side of the SNA organization. In this scenario they
were still harboring hopes that they could prevail over the SNA
organization and get out their high-speed fiber optic interconnect
... and have it available crossing the machine room boundary.  The POK
interconnect group felt that the HYPERChannel interconnect was
(potentiallY) as much a longterm threat to their objectives as it was
a threat to the SNA organization's products (so it was time to circle
the wagons, forget for the moment their differences and oppose the
common enemy).

ref:
http://www.garlic.com/~lynn/2005r.html#14 Intel strikes back with a parallel x86 design

several years later I was able to ship RFC1044 support in mainframe
tcp/ip product ... but then (at the time) neither the SNA organization
or the POK interconnect group really thot that TCP/IP support was much
of an issue/threat. misc. collection 1044 postings
http://www.garlic.com/~lynn/subnetwork.html#1044

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

Intel strikes back with a parallel x86 design

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Sun, 02 Oct 2005 15:10:02 -0600

ref:
http://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design

the modified PC 3270 emulator was available with support for TCA cards
(to 3274) and called MYTE; PCCA was the 16bit ISA mainframe channel
interface card.

a reference from long ago and far away:

The demo they had with PCCA on PCNET was various host connections was
quite impressive, both terminal sessions and file transfer. Terminal
sessions supported going "both ways" ... PVM from PCDOS over PCNET to
AT with PCCA, into 370 PVM and using PVM internal net to log on
anywhere. A version of MYTE with NETBIOS support is used on the local
PC machine. They claim end-to-end date rate of only 70kbytes per
second now ... attributed to bottlenecks associated with NETBIOS
programming. They could significantly improve that with bypassing
NETBIOS and/or going to faster PC-to-PC interconnect (token ring,
ethernet, etc). However, 70kbytes/sec is still significantly better
than the 15kbytes/sec that Myte gets using TCA support thru 3274.

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

SATA woes

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SATA woes
Newsgroups: comp.os.linux.hardware,redhat.hardware.arch.intel,comp.os.linux.redhat,comp.os.linux.hardware,linux.redhat.install,redhat.kernel.general
Date: Sun, 02 Oct 2005 17:02:58 -0600

Whoever writes:

I have been trying to install RedHat Enterprise Workstation 4 on a system
based on the Intel 945G chipset with a SATA disk.

By configuring the drive mode to be ATA/IDE in the BIOS, I was able to
install the OS (but very slow, because disk access is very slow).

I was able to download some updates -- including a later kernel, but now
the system won't boot with the latest kernel (it still boots with the
older kernel). The new (non-booting) kernel is 2.6.9-11 (with a -EL or
similar suffix, I am not in front of the system right now).

as an aside ... does FC4 install handle SATA disks. FC3 did a clean
install on a machine I have with SATA raid. However, somewhere in the
FC3 cycle ... the YUM kernel installs dropped SATA support. Then
after doing a YUM kernel install ... i would have to rebuild the
FC3 kernel with SATA support before rebooting ... aka

/sbin/mkinitrd --with=sata_promise --with=ata_piix --with=sd_mod
    -f initrd-2.6.12-1.1378_FC3smp.img 2.6.12-1.1378_FC3smp

a scratch FC4 install will wipe my FC3 bootable system ... but I don't
want to try it ... if the base FC4 install might fail to include SATA
support ...leaving me with an unbootable system.

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

Intel strikes back with a parallel x86 design

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Mon, 03 Oct 2005 09:15:57 -0600

"gerard46" writes:

After ten years of mediocore response time, I suppose anybody can
get used to anything.  But once you get on a system with subsecond
response times (say, 1/3 second), anything over a second seems long,
and when it gets over two seconds, it seems intolerable.  It all
boils down to what you get used
to. _______________________________________________Gerard S.

there was actually a study about human factors and response time
... and unpredictable response time turned out to be a significant
factor ... if people got use to 2 second response time ... they would
change their behavior to accomodate the infrastructure. however, if
there was significant variability between 1 second and 3-4 seconds,
they might do something based on expecting 1 second ... and then have
to wait until it was really ready. this degraded human performance by
a factor of twice the difference between the expected and the actual.

there was an corporate conference held at the original marriott in
wash dc in the early 70s ... where Mills spoke about super programmer
and some HF group spoke on human performance and system response. they
measured a bunch of people at research ... and found that human
throughtput consistently improved with system response down until
about .25seconds. Between .25seconds and .1second it became somewhat
variable ... apparently differences between individuals. Some people
didn't notice the difference between .25 and .1 second response, and
some people would notice all the way down to .1 seconds (which was
about the best they measured in any individual).  they claimed to not
find any correlation between threshold percention of different
individuals and other characteristics. I have vague recollection of
running across an article in the early 80s on study of brain synapse
propagation time and finding individual variability ... which may or
may not have any correlation with individual response perception
threshold.

it did give rise to some derogatory jokes about tso users not being
able to perceive difference between greater than second response and
subsecond response.

part of the MVS TSO issue involved MVS system structure ... and wasn't
solely TSO's fault.

sjr/bldg28 for a period had a pair of 370s all sharing the same disk
control units, a 370/168 for MVS and a 370/158 for VM370/CMS. The
operators were instructed to keep disk mounts segragated between disk
controllers identified as MVS and controllers identified as VM. The
issue is that MVS normal disk operation includes multi-track search
operations which could create solid control busy lock-up for as long
as 1/3rd second for a single operation. A controller would typically
have 16 disk drives ... and when a controller was busy in this manner,
the other 15 disk drives were unavailable during the busy period
(i.e. you might expect something like 20-40 accesses per second per
disk ... in this worst case scenario, things might degrade to a total
of 3 access per second per controller ... total, across all 16
drives).

one day, an operator accidently mounted a "MVS" disk on a "VM"
controller/drive. within five minutes the datacenter operations were
getting phone calls from irate cms users howling about system response
having just gone down the drain.

besides the normal TSO characteristics not being sensitive to human
factors and system response ... the underlying MVS platform wasn't
conducive to fine-grain response. the incident was a great example
that not only didn't TSO users realize how bad it really was ... but
how the underlying MVS platform contributed to TSO not being able to
provide response (i.e. TSO users ran day in & day out ... with all
MVS disks operating with the charactistics that CMS users found
totally intolerable when subjected to just a single disk operating in
that manner).

lots of past posts about the effect of multi-track search on response
and thruput
http://www.garlic.com/~lynn/submain.html#dasd

note that the extensive use of multi-track search could become so bad
that it would even effect MVS shops. I got brought into a large
customer shop that didn't have any vm370 at all. It was a datacenter
for a large national retailer ... that had basically processor per
region ... but sharing common disk infrastructure. they were
experiencing random slow-downs that appeared to almost bring the whole
complex nearly to its knees. It turned out to be an issue with a large
application library partitioned data set ... that when things really
got busy during the day ... all the systems were constantly loading
members from the same library. The PDS had a 3cyliner directory and
each member load required, on the avg. a 1.5cylinder multi-track
search of the directory (taking approx. .5 seconds elapsed time).

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

Intel strikes back with a parallel x86 design

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch,comp.sys.intel,comp.sys.ibm.pc.hardware.chips
Date: Mon, 03 Oct 2005 10:08:48 -0600

"gerard46" writes:

After ten years of mediocore response time, I suppose anybody can
get used to anything.  But once you get on a system with subsecond
response times (say, 1/3 second), anything over a second seems long,
and when it gets over two seconds, it seems intolerable.  It all
boils down to what you get used
to. _______________________________________________Gerard S.

another indication about how bad TSO response was (especially
vis-a-vis CMS potentially running on identical hardware configuraiton
and effectively similar load) ... was that in the late 70s and early
80s ... some number of startups actually got VC money for doing 3274
clone controllers that featured TSO "offload".

typical CMS trivial interactive response would included some disk
operations ... even when TSO trivial interactive response was defined
to exclude operations involving disk ... there was still a significant
response issue. 3274 controller clones ... would provide front end
processing for some number of frequent TSO interactive operations (for
the connected 327x terminals) ... attempting to mask the horrible
system backend operation (and the remarkable thing was this was so
well recognized that you could even get VC money for startups doing
it). With the eventual proliferation of PCs with terminal emulation,
the front-end TSO offload (backend response masking) could be moved to
the PC ... obsoleting the need for the 3274 controller clones.

there used to be a joke in the valley that there were actually only
200 people ... they just milled around in different disguises.

One of the 3274 controller clone startups was done by somebody who had
been in the vlsi tools group in Los Gatos lab (bldg. 28) and also one
of the two people responsible for the 370 pascal compiler (originally
developed for writing of internal vlsi tools). He then went on to be
VP of software development at MIPs and at the first JAVA conference
... showed up as general manager of the SUN group that included JAVA.

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

z/VM Listserv?

From: Anne & Lynn Wheeler <lynn@GARLIC.COM>
Subject: Re: z/VM Listserv?
Newsgroups: bit.listserv.ibm-main
Date: Mon, 3 Oct 2005 09:57:03 -0600

Juraschek, David F wrote:

I've been to MARIST & L-Soft.

Is there a z/VM (or just a VM) listserv address?

... vmesa-l@listserv.uark.edu

traditional listserv to subscribe/unsubscribe
LISTSERV@LISTSERV.UARK.EDU

note that both ibm-main and vmesa-l are gatewayed to usenet as
bit.listserv.ibm-main and bit.listserv.vmesa-l. I find that usenet posts
to bit.listserv.vmesa-l actually flow in the reverse direction ...
however for posts to actually show up in the ibm-main mailing list ...
you have to actually mail to the ibm-main listserver.

the "bit.listserv" usenet hierarchy dates from the bitnet/earn days
http://www.garlic.com/~lynn/subnetwork.html#bitnet

when bitnet mailing lists were gatewayed from bitnet to internet.

z/VM Listserv?

From: Anne & Lynn Wheeler <lynn@GARLIC.COM>
Subject: Re: z/VM Listserv?
Newsgroups: bit.listserv.ibm-main
Date: Mon, 3 Oct 2005 10:53:22 -0600

Ed Finnell wrote:

It's a configuration option in lSoft for bidirectional flow. We've
talked about it numerous times in the past. Back in the late 90's when
American .edu dropped usenet for lack of interest, personnel, budget
Google was just starting up and started gating to the usenet
groups. In their never ending search for eMail addresses also allowed
subscription to their copies of the original lists. Darren found out
early on that the Lsoft exits weren't sufficient for uunet protocol
and had to turn off bidirectional posting. The 'true' newsgroup is
hosted by newsguy.com(it's a subscription too). With the advent of the
harvesting .bots and SPAMmers more and more is intercepted and
transmogrified in the lsoft exits.

i had done some mailing list stuff on the internal network
http://www.garlic.com/~lynn/subnetwork.html#internalnet

that predated toolsrun ... in fact, there is some folklore that
toolsrun somewhat came out as a result of a corporate task force that
was formed to investigate what was going on (some even leaked and
showed up in datamation article blaming me, the authors of network
nation from njit were also brought in as part of the
investigation). some version of toolsrun was then shared with bitnet
participants giving rise to early listserv.

another fall-out was i got a researcher in the back of my office for
nine months that took notes on how i communicated, went with me to
meetings, got copies of all my incoming/outgoing email and logs of all
instant messages. The analysis eventually resulted in a Stanford phd
thesis (joint between computer ai and language) and subsequent papers
and books ... somewhat in the area of computer mediated communication
http://www.garlic.com/~lynn/subnetwork.html#cmc

my first usenet/newsgroup reader back in the late 80s was in emacs ...
and i still do majority of my usenet/newsgroup activity in emacs client.

OS's with loadable filesystem support?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OS's with loadable filesystem support?
Newsgroups: alt.folklore.computers
Date: Mon, 03 Oct 2005 17:26:39 -0600

"Jack Peacock" writes:

It lives on in the way a database manager still does much the same thing, in
terms of managing database pages in memory vs. on disk.  Page I/O is
typically in block format, some multiple of sector size, with the disk file
treated as a linear number of database pages, not so different from a SCSI
disk appearing as a linear list of blocks.  The database writer is
essentially a virtual memory system, mapping the entire disk file into
memory (assuming a 64-bit address for largers DBs), then caching disk blocks
in memory from that linear list.

Wasn't it common on Unix systems at one time to install database files in
raw partitions, due to the 32-bit addressing limits on filesystems?

In practical terms using physical geometry isn't practical anymore because
of zone recording, where the number of sectors per track varies by distance
from the center spindle, so SCSI went to a block number instead (and IDE too
when ATAPI came into being).

raw was to avoid standard unix filesystem caching and poor
consistency.  with raw ... the dbms had a pretty good idea of what was
actually on disk and what was actually in memory and when there were
transitions between the two. raw useage predates 32bit addressing
becoming a limitation.

for decades, unix filesystems had been notorious for their extremly
poor disk surface consistency operation.  you have a filesystem that
couldn't satisfy acid properties ... and, in turn, it was difficult to
create a dbms that would use standard filesystem operation and still
satisfy acid properties.

the later generations of journal/logging unix filesystems tended to be
just for filesystem metadata ... to somewhat avoid loosing the whole
system because of filesystem corruption ...  but still tended to
retain traditional unix filesystem inconsistency characteristics for
actual file data (distinct from filesystem meta/control data).

random search engine reference for acid properties
http://www.service-architecture.com/database/articles/acid_properties.html
http://en.wikipedia.org/wiki/ACID
http://databases.about.com/od/specificproducts/a/acid.htm

for a little topic drift ... system/r was the original relational/sql
implementation
http://www.garlic.com/~lynn/submain.html#systemr

and one of the consumers of global lock manager for ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

was distributed database operation,

one of the things that posix (async) i/o attempted was to provide
ability to use standard filesystem allocation/deallocation of disk
surface but perform direct i/o (reads and writes) with direct control
between the disk surface and processor memory space (bypassing most of
the standard unix filesystem operations). posix i/o can be intertwined
with memory mapped operation.

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

What ever happened to Tandem and NonStop OS ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What ever happened to Tandem and NonStop OS ?
Newsgroups: alt.folklore.computers
Date: Mon, 03 Oct 2005 22:56:41 -0600

Marco S Hyman writes:

I'd date them to the early 80s with the start of Apollo (1980) and
Sun (1982).  The Xerox Star came out about then, too.   I think the
Lilith was earlier.  I remember being blown away by an Intergraph
CAD system, also in the early 80s.

perq from 79
http://en.wikipedia.org/wiki/PERQ

when the people that wanted to build this new sun workstation thing
came around ... i have vague recollection that one of the groups that
evaluated the proposal had a bunch of perq that they were using.

i also remember some number of calmas
http://en.wikipedia.org/wiki/Calma

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

PCI audit compliance

From: Anne & Lynn Wheeler <lynn@GARLIC.COM>
Subject: Re: PCI audit compliance
Newsgroups: bit.listserv.ibm-main
Date: Tue, 4 Oct 2005 07:34:38 -0600

Jousma, David wrote:

Brian,

You don't mention it, but I'm assuming you are a RACF shop.  If so, I
have a password exit that allows enforcement of various password quality
rules, like repeating characters, new pw to similar to old one, etc.  It
is very modular, so you could take out checks your company doesn't need.
Let me know if you are interested.

Dave

for a little drift, from long ago and far away:
http://www.garlic.com/~lynn/2001d.html#51 OT Re: A beautiful morning in AFM.
http://www.garlic.com/~lynn/2001d.html#52 OT Re: A beautiful morning in AFM.

lots of collected past posts on issues with shared-secret based
authentication
http://www.garlic.com/~lynn/subintegrity.html#secret

and collected past posts on 3-factor authentication paradigm
http://www.garlic.com/~lynn/subintegrity.html#3factor

part of the issue is that basic security principle is that unique,
hard-to-guess and impossible to remember shared-secrets are required
for every unique security domain (countermeasure for cross-domain
contamination ... say like your local garage ISP login and you online
banking service). This tends to be somewhat institutional-centric with
every institution (security domain) assuming that it is the only
"real" operation where you would have a hard-to-guess and impossible
to remember password (and then multiply that times a couple dozen such
environments).

some number of recent news URLs related to the subject

Password overload is costing money
http://www.theinquirer.net/?article=26653
Multiple passwords creating insecurity
http://www.computeractive.co.uk/computing/news/2143054/multiple-passwords-creating
Multiple passwords creating insecurity
http://www.itweek.co.uk/computing/news/2143054/multiple-passwords-creating
Multiple passwords creating insecurity
http://www.vnunet.com/computing/news/2143054/multiple-passwords-creating

VM tape definitions

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: VM tape definitions
Newsgroups: bit.listserv.vmesa-l
Date: Tue, 04 Oct 2005 07:46:51 -0600

Jim Bohnsack writes:

My "guess" is that the CE did not define any more than 8 devices in
the 1025 CU (E60) and only 4 devices in the 1021 CU (5A0).  The 3480
control units are sensed so the only info the system really has is
what is returned to it.  This is much better than having all 32 or
16 or whatever is the max number of devices for a 3480 CU defined to
the physical CU and you only having 8 devices defined in the IOCDS.
On occasion when the CU has some info to pass back to the OS, it
will use an address in the high range that has been physically
plugged into it and the IOCDS doesn't have an IODEVICE at that
address.  Then you get a funny error message saying that there is
sense info but no place to stuff it into.

controllers used to have this situation called contingent connection
after a unit check ... having only one place in the controller for
holding status information ... they would expect the system to
immediately do a sense operation on the address that had the unit
check. If you attempted an operation on a different device address,
the controller would return sm+busy ... and them a CUE interupt with
the device address (on the controller) that had the pending sense
information.

if there was a mismatch between the system configuration definition
and the hardware ... you could get system hang &/or tight-loop.

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

transactional memory question

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: transactional memory question
Newsgroups: comp.arch,comp.programming.threads
Date: Tue, 04 Oct 2005 09:25:54 -0600

"Chris Thomasson" <_no_spam_cristom@no_spam_comcast._net> writes:

IMHO, I believe its too early in the game for actual hardware
support, even though they really do need it in order for TM to
become really useful. All of the software emulations I have seen are
loaded with expensive atomic operations; mutexs seem more
efficient...

early 801 had a form ... it was used by journal filesystem for aix in
rs/6000.

filesystem metadata was organized ... and the memory system caught all
changes ... so basically you avoided having to do all the explicit
logging/locking statements in the filesystem code ... you did have to
add commit calls.

there was some disagreement whether the overhead of explicit
logs/locks were more expensive than the implicit overhead involved in
transaction memory. turns out there was the overhead of scanning the
whole memory area for changes at commits.

a portable version of the journal filesystem code with explicit
lock/logging changes in the code turned up the explicit lock/logging
calls had lower overhead than transactional memory (at least in the
journal filesystem case).

and unrelated old reference from about same period as aixv3 ... the
Proceedings of the 20th International Symposium on Fault-Tolerant
Computing Systems, pp 89--96, Newcastle, June 1990.

A Fault Tolerant Tightly Coupled Multiprocessor Architecture based on
Stable Transactional Memory

Authors: Michel Banatre and Philippe Joubert
Abstract:

Traditionally, tightly coupled multiprocessors allow data sharing
between multiple caches by keeping cached copies of memory blocks
coherent with respect to shared memory. This is difficult to achieve
in a fault tolerant environment due to the need to save global
checkpoints in shared memory from where consistent cache states can be
recovered after a failure.

The architecture presented in this report solves this problem by
encapsulating the memory modifications done by a process into an
atomic transaction. Caches record dependencies between the
transactions associated with processes modifying the same memory
blocks. Dependent transactions may then be atomically committed. Such
an operation requires a cache coherence protocol responsible for
recording process dependencies as well as keeping coherent cached
copies of blocks and a shared Stable Transactional Memory owing to
which all memory updates are atomic to allow recovery after a
processor failure.

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

Intel strikes back with a parallel x86 design

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Intel strikes back with a parallel x86 design
Newsgroups: comp.arch
Date: Tue, 04 Oct 2005 12:08:48 -0600

Edward Wolfgram writes:

Tsk tsk.  Really, this TSO bashing has got to stop. Uninformed lurkers
here will think there is something wrong with TSO, and by extension,
perhaps even MVS and mainframes!

it didn't start out to be TSO bashing ... the long wandering thread
sort of started out that terminal emulation contributed to some
signifcant product uptake for the ibm/pc ... but later, efforts to
protect the installed terminal emulation business contributed
significantly to opposing moving on to better solutions
http://www.garlic.com/~lynn/subnetwork.html#emulation

that SAA was part of the effort to help circle the wagons around the
installed terminal emulation business ... attempting to stuff the
client/server genie back into the bottle. we caused them heartburn at
the time ... out doing customer executive presentations on 3-tier
architecture
http://www.garlic.com/~lynn/subnetwork.html#3tier

the 3274/3278 ref. was going back to some pre-ibmpc history (of the
communication division). there had been some hardware hacks to the
(3272/)3277 terminal ... that made it almost tolerable for interactive
computing. the 3274/3278 was a regression from the basic 3272/3277
... and because they moved a lot of the electronics (that had been in
the 3277 terminal) back into the 3274 controller (cutting down on 3278
manufacturing costs), it made similar hardware hacks to the 3278
impossible.

complaining about how poor the 3274/3278 was for interactive computing
... got us a response back from the product group ... that the
3274/3278 wasn't intended for the interactive computing market segment
... it was for the data entry market segment ... and was better than
keypunches.  The TSO product group came down on the 3274/3278 side
... effectively taking the position that TSO had never been intended
for the interactive computing market segment and/or never been
intended to have better than 1 second response (and that was for
strictly non-SNA, local, channel attached controllers).

that doesn't mean you couldn't do some tweaks and control the
environment to improve on TSO operation ... but it was trying to use
it for something that it wasn't intended for.

in the 1980 time-frame the standard TSO design-point was so well known
... that startups could get VC money for 3274-clones that did TSO
offload ... attempting to provide a reasonably tolerable human
interfacw where TSO was involved (by pre-handling some interactions in
the 3274 controller clone ... as opposed to going all the way back to
TSO).

now, up until about mid-85 ... the internal network was larger than
the arpanet/internet ... from just about the beginning ...
http://www.garlic.com/~lynn/subnetwork.html#internalnet

and the majority were non-MVS for various reasons ... in part because
internal development made extensive use of non-MVS interactive
computing ... even when MVS related development was involved (so a
preponderance of internal systems were non-MVS). Another was that
nearly all of the internal MVS systems were built with JES2 ... and
used JES2 for MVS networking support ... and JES2 networking support
had enormous limitations. a few, somewhat related postings
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#0 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#7 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#15 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#16 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#19 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#30 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#32 HASP/ASP JES/JES2/JES3

as an aside ... as an undergraduate ... I had modified an MVT/HASP
system ... incorporating 2741 & TTY support into HASP and implementing
HASP interactive interface ... borrowing CMS editor syntax for part of
the design. This provided a lot of TSO-like functionality for doing
program creation and submission. lots of past posts mention all sorts
of HASP references
http://www.garlic.com/~lynn/submain.html#hasp

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

Job seperators

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Job seperators
Newsgroups: bit.listserv.vmesa-l
Date: Wed, 05 Oct 2005 13:39:27 -0600

Rich Smrcina writes:

Are printed job seperators an all or nothing sort of thing?  I know
that they can be turned off, but is there a configuration option to
just print one page before and after a job, instead of two pages?

vm seperators were somewhat modeled after hasp ... for fanfold paper
... you had two pages at the start of the print item ... since you
didn't know whether it was starting on a even or odd page. when the
operators bursted the print stream into separate items you wanted a
face-up separator page. with only one page before a print item ... on
the avg., half the time it would be on a face down page ... and the
face-up would be the back of the seperator page (people thumbing thru
the stack would have a lot harder time recognizing what they were
looking for. the trailing page after also had a solid block of chars
at the bottom of the page ... when the operator pulled a couple foot
stack of fan-fold paper from the printer ... there was some chance
that the dark block of printed chars could be seen looking at the
stack of paper from the side ... aiding the operator identify where to
burst the stack of paper into separate items.

when sjr did some 6670 driver support for RSCS ... it did a single
separator page from the alternate paper drawer (which was then loaded
with colored paper ... eliminating the issue requiring dual starter
pages with fan-fold so there is one face-up ... and block of chars on
the bottom of the trailing page aiding the operator in finding
start/end) ... with the traditional identification information.
however, since the rest of the page was mostly blank ... there was
special addition to pull a random entry from a ibm jargon definition
file and print that. search engine found old online version:
http://www.212.net/business/jargon.htm

two early issues with the output 6670s distributed around bldg. 28
were:

1) one weekend somebody printed an "April 1st" corporate memorandum on
corporate letterhead paper and had it in all the bldg. corporate
bulletin boards monday morning.

2) during one audit by corporate security ... they were looking for
confidential output being left at 6670s ... and they found a separator
page with an item giving the definition of auditor ... which they took
personally.

random past postings mentioning 6670 and/or jargon references:
http://www.garlic.com/~lynn/99.html#42 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
http://www.garlic.com/~lynn/99.html#43 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
http://www.garlic.com/~lynn/99.html#52 Enter fonts (was Re: Unix case-sensitivity: how did it originate?
http://www.garlic.com/~lynn/2000b.html#29 20th March 2000
http://www.garlic.com/~lynn/2000d.html#81 Coloured IBM DASD
http://www.garlic.com/~lynn/2000e.html#1 What good and old text formatter are there ?
http://www.garlic.com/~lynn/2001b.html#50 IBM 705 computer manual
http://www.garlic.com/~lynn/2001g.html#5 New IBM history book out
http://www.garlic.com/~lynn/2001n.html#31 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2002e.html#45 REXX and its designer (was: IBM 7090 instruction set)
http://www.garlic.com/~lynn/2002h.html#7 disk write caching (was: ibm icecube -- return of
http://www.garlic.com/~lynn/2002m.html#52 Microsoft's innovations [was:the rtf format]
http://www.garlic.com/~lynn/2002o.html#24 IBM Selectric as printer
http://www.garlic.com/~lynn/2002o.html#29 6670
http://www.garlic.com/~lynn/2003b.html#19 Card Columns
http://www.garlic.com/~lynn/2003c.html#43 Early attempts at console humor?
http://www.garlic.com/~lynn/2003n.html#49 Rant (Re: Programmer's unpaid overtime)
http://www.garlic.com/~lynn/2003o.html#0 Weird new IBM created word
http://www.garlic.com/~lynn/2004c.html#1 Oldest running code
http://www.garlic.com/~lynn/2004c.html#23 Jargon Files Wanted
http://www.garlic.com/~lynn/2004d.html#13 JSX 328x printing (portrait)
http://www.garlic.com/~lynn/2004k.html#48 Xah Lee's Unixism
http://www.garlic.com/~lynn/2004l.html#61 Shipwrecks
http://www.garlic.com/~lynn/2004l.html#69 IBMism
http://www.garlic.com/~lynn/2004o.html#46 Integer types for 128-bit addressing
http://www.garlic.com/~lynn/2005f.html#34 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005f.html#48 1403 printers
http://www.garlic.com/~lynn/2005f.html#51 1403 printers
http://www.garlic.com/~lynn/2005f.html#54 1403 printers
http://www.garlic.com/~lynn/2005g.html#19 DOS/360: Forty years

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

File path formats

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: File path formats.
Newsgroups: alt.folklore.computers
Date: Wed, 05 Oct 2005 14:58:36 -0600

Rob Storey writes:

IBM CMS:-

FILENAME FILETYPE FILEMODE

Name and Type are up to 8 characters each.
Mode is 2 chars: Alpha+Numeric. The alpha indicates the letter
assigned to the minidisk via a previous "access" command, the numeric
indicated access mode (usually "1", can't remember what the values
mean).

from my trusty 1968 CP67/CMS users manual

0      ... only shows with r/w access, doesn't appear with r/o access
1 or 5 ... file may be written or read
2 or 6 ... file is read-only
3      ,,, file may be written or read, but is erased when file is closed
4      ... file is read-only, and is erased when the file is closed

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

Symbols vs letters as passphrase?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Symbols vs letters as passphrase?
Newsgroups: comp.security.misc
Date: Wed, 05 Oct 2005 18:57:12 -0600

Peter Frank writes:

The encryption software I use offers me two choices for entering a
passphrase:
1) an ordinary password consisting of letters, numbers and/or special
characters
2) 10 symbols that can be clicked in any order to form a "passphrase"

How safe is a "passphrase" consisting of maybe 15 symbol clicks
compared to a password consisting of 15 letters, numbers and/or
special characters?

Let's assume the password was chosen carefully, so it contains no
known words or derivations thereof, and special characters and numbers
were used.

Is the password safer because there are many more letters, numbers,
and special characters than symbols to choose from?

"safe" can be a combination of several things. creation of passwords
that are totally impossible to remember ... make them harder for an
attacker to guess ... but also result in human's writing them down
... providing an attacker with more than one avenue for obtaining the
password.

shared-secret passwords also have a requirement that unique shared-secrets are required for different security domains (cross-domain
compromise ... i.e. the password at your local garage ISP being the
same as your online banking access). difficulty of memorizing goes up
both as the complexity of the password as well as the number of
different passwords. i got my first password nearly 40 years ago
... and at the time, I only had one. Now I'm faced with managing
scores of passwords. then if they have to be changed every month, the
problem can reach truely hopeless state:
http://www.garlic.com/~lynn/subintegrity.html#secrets

then there are the rules excluding certain values ... here is an
corporate directive April 1st version from over 20 years ago
... parody explains how there is only one acceptable password.
http://www.garlic.com/~lynn/2001d.html#52 OT Re: A beautiful morning in AFM

some recent news articles ... effectively institutional-centric
paradigm running afoul of person related limitations.

Password overload is costing money
http://www.theinquirer.net/?article=26653
Multiple passwords creating insecurity
http://www.computeractive.co.uk/computing/news/2143054/multiple-passwords-creating
Multiple passwords creating insecurity
http://www.itweek.co.uk/computing/news/2143054/multiple-passwords-creating
Multiple passwords creating insecurity
http://www.vnunet.com/computing/news/2143054/multiple-passwords-creating
Now, what was my September password?
http://www.purdueexponent.org/index.php/module/Issue/action/Article/article_id/1168
Too Many Passwords
http://it.slashdot.org/it/05/09/27/1935210.shtml?tid=172&tid=218
Authentication | Password Overload Makes Enterprise Systems Less
Secure
http://www.techweb.com/wire/security/171201073
Password overload plagues US.biz
http://www.theregister.com/2005/09/27/password_overload_survey/
Password Overload Makes Enterprise Systems Less Secure
http://news.yahoo.com/s/cmp/20050928/tc_cmp/171201073;_ylt=A9FJqZNytzpDEWgAlgYjtBAF;_ylu=X3oDMTBiMW04NW9mBHNlYwMlJVRPUCUl
Survey shows signs of security password overload
http://www.cbronline.com/article_news.asp?guid=7778865B-DD3A-4230-9968-83244D713FBE
Password overload plagues US.biz
http://www.securityfocus.com/news/11331

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

How does the internet really look like ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: How does the internet really look like ?
Newsgroups: comp.dcom.sys.cisco,comp.protocols.tcp-ip
Date: Thu, 06 Oct 2005 10:48:59 -0600

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:

Packets between two different major providers cross on "multihomed"
routers that are run in cooperation with both providers. Often there
will be several such crossover points ("peering"). For any one packet
in transit, the choice of cross-over point depends upon the policies
(and charging structures!) agreed upon between the providers, and
upon which links are reachable and not overloaded at the time.

a couple recent news items regarding glitches w/peering:

Internet Partitioning - Cogent vs Level 3?
http://ask.slashdot.org/askslashdot/05/10/05/2247207.shtml?tid=95&tid=187&tid=4
Level 3 depeers Cogent
http://www.theregister.com/2005/10/06/level3_cogent/
Level 3 Peering Changes Causing Headaches; Roadrunner, Cogent users
unable to hit major sites
http://www.anandtech.com/news/shownews.aspx?i=25035

when we were doing original payment gateway
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

we were looking at some of the availability issues ... with things
like multi-homing, replicated components, multiple paths into
different parts of top level infrastructure, etc. ... in part, having
previously done ha/cmp project
http://www.garlic.com/~lynn/subtopic.html#hacmp

right in the middle of that, there was decision to migrate to
hierarchical routing policy ... because the purely dynamic routing
tables weren't scaling as the internet size grew ... aka some of the
stuff that could have been done for high availability with dynamic
routing advertisement ... went away. at that point ... the primary
remaining strategy was multiple A-record support. since we had some
amount of sign-off ... we could mandate it for the webservers to the
payment gateway. however, we for webserves and e-commerce, it was also
important for browsers to also support multiple A-record support.

A trivial example was an early major e-commerce website was sports
related ... which did some major advertisement and offerings during
Sunday afternoon football ... and hoping to get traffic during
half-time. Their ISP at the time was still into taking down major city
centers on Sunday afternoon for various maintenance tasks. They needed
alternate paths to major internet backbone ... and browsers capable of
tracking alternate paths. It didn't do much good to have redundant
links into carefully selected points from various ISPs ... if the
basic infrastructure couldn't deal take advantage of the redundant
links.

a major feature of the IMP-based arpanet in the 70s was dynamic route
finding. The IMP operation formed a homogeneous infrastructure
... with the IMPs interconnected by 56kbit links. There were folklore
stories in the late 70s that the IMP dynamic routing infrastructure
overhead was sometimes consuming 40kbit-50kbit of the available 56kbit
with dynamic routing information chatter (another case where dynamic
routing was having difficulty scaling).

the switch-over from homegeneous networking to internetworking and
gateways was on 1/1/83. This is part of my frequent postings that
the internal network was larger than the internet/arpanet from just
about the beginning until mid-85 ... in part because the major nodes
in the internal network had effectively a form of gateway support from
the beginning
http://www.garlic.com/~lynn/subnetwork.html#internalnet

the transition to modern internet as an operatinal characteristic
... as opposed to technology transition (aka 1/1/83) was with the
NSFNET backbone
http://www.garlic.com/~lynn/2002k.html#12 NSFNET Program Announcement
http://www.garlic.com/~lynn/2000e.html#10 NSFNET Award Announcement

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

The 8008

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: The 8008
Newsgroups: alt.folklore.computers
Date: Thu, 06 Oct 2005 14:04:13 -0600

Andrew Swallow writes:

Or an old  Hong Kong style government.  The one before
Hong Kong returned to China.

ha/cmp early adopters were in the far east
http://www.garlic.com/~lynn/subtopic.html#hacmp

and spent some amount of time in HK, staying over on the Kowloon side
and walking down to the star ferry in the morning to take across the
bay.

some number of asians expressed some opinion of descrimination by the
British ... some estimates that being British was worth 30 percent
business premium over asians (in HK). as a result there were some
comments that it might be hard to decide which might be better (or
worse) given the upcoming change of control (at least if you were
non-british).

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

logical block addressing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: logical block addressing
Newsgroups: alt.folklore.computers
Date: Thu, 06 Oct 2005 14:43:37 -0600

"Tim Shoppa" writes:

I wouldn't say that.  But I would say that posting a Wiki "answer" that
only deals with PC-clones to an a.f.c thread expressly dealing with
Lasnerian 1960's technology is useless.

Other Wiki articles are not too far off the mark with respect to
technology history.  They aren't always written from my viewpoint but
they are in some way or another relevant.

in posting to comp.arch thread
http://www.garlic.com/~lynn/2005q.html#40 Intel strikes back with a parallel x86 design

noted that a wiki article on power/pc ... claimed that POWER was
retrofitted to RIOS after the advent of power/pc ... even tho POWER
was used from the very start with RIOS ... and power/pc didn't show
up until later ... after the onset of somerset to develop power/pc
http://en.wikipedia.org/wiki/PowerPC

aka power/pc was created to differentiate a single chip (simpler)
version of power ... "POWER" already was inuse extensively to describe
RIOS/RS6000. I have a clear green-tinted plexiglass paper weight on my
desk that was used to commemorate original POWER/RS6000 announce
... has six chips and legend

"AWD Austin & GTD Burlington"
"POWER Architecture"

above the six chips and

150 Million OPS
60 Million FLOPS
7 Million Transistors

below.

some number of past posts mentioning somerset
http://www.garlic.com/~lynn/2000d.html#60 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
http://www.garlic.com/~lynn/2001g.html#23 IA64 Rocks My World
http://www.garlic.com/~lynn/2001i.html#28 Proper ISA lifespan?
http://www.garlic.com/~lynn/2001j.html#37 Proper ISA lifespan?
http://www.garlic.com/~lynn/2002g.html#12 "Soul of a New Machine" Computer?
http://www.garlic.com/~lynn/2002g.html#14 "Soul of a New Machine" Computer?
http://www.garlic.com/~lynn/2002i.html#81 McKinley Cometh
http://www.garlic.com/~lynn/2002l.html#37 Computer Architectures
http://www.garlic.com/~lynn/2003d.html#45 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003d.html#57 Another light on the map going out
http://www.garlic.com/~lynn/2003j.html#22 why doesn't processor reordering instructions affect most
http://www.garlic.com/~lynn/2004.html#28 Two subjects: 64-bit OS2/eCs, Innotek Products
http://www.garlic.com/~lynn/2004d.html#1 IBM 360 memory
http://www.garlic.com/~lynn/2004k.html#39 August 23, 1957
http://www.garlic.com/~lynn/2004q.html#36 CAS and LL/SC
http://www.garlic.com/~lynn/2004q.html#38 CAS and LL/SC
http://www.garlic.com/~lynn/2004q.html#39 CAS and LL/SC
http://www.garlic.com/~lynn/2004q.html#40 Tru64 and the DECSYSTEM 20
http://www.garlic.com/~lynn/2005.html#40 clusters vs shared-memory (was: Re: CAS and LL/SC (was Re: High Level Assembler for MVS & VM & VSE))
http://www.garlic.com/~lynn/2005e.html#7 Misuse of word "microcode"
http://www.garlic.com/~lynn/2005m.html#12 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005m.html#13 IBM's mini computers--lack thereof
http://www.garlic.com/~lynn/2005o.html#37 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005p.html#14 Multicores
http://www.garlic.com/~lynn/2005q.html#40 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#11 Intel strikes back with a parallel x86 design

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

X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique
Newsgroups: sci.crypt
Date: Fri, 07 Oct 2005 16:15:27 -0600

tomstdenis writes:

Such a language exists?

note that this periodically gets repeated ... some collected posts
from a year ago ... and prior years
http://www.garlic.com/~lynn/subintegrity.html#overflow

however there are languages and environments where the frequency of
such things happening are drastically smaller (possibly two orders of
magnitude smaller) for this class of mistakes.

i was involved in a tcp/ip stack implementation in the 80s that was
done in pascal ... and was not known to have any of the overflow
vulnerabilities that seem to be so common. in part, because a lot of
the buffer-to-buffer type operations didn't depend on the programmer
having to manage the bounds of the target ... it was built into the
operations. as a result, there were significantly fewer situations
where the opportunity for making target length related mistakes.

I've also been involved in purely assembler-based implementations
where the underlying environmental bounds semantics existing for all
buffers ... and it was standard programming convention to always
utilize the target bounds/lengths.

In one case, the target bounds/lengths were built into the programming
language ... and in the assembler case, the related environment
(libraries, standard system features, etc) established programming
convention that encouraged the use of bounds paradigm on all
operations. In both situations, while the environment didn't
absolutely prevent bounds violations ... the frequency of bounds
violations were something like two-orders of magnitude less.

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

X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique
Newsgroups: sci.crypt
Date: Fri, 07 Oct 2005 17:16:02 -0600

tomstdenis writes:

How hard is it to do checks as you decode fields?  e.g. you know
your input is "inlen" bytes and you just decoded a field length 'k'.
Check if k+current_read>inlen ... not hard.

the standard C convention is that a target buffer doesn't have an
infrastrcture related length ... it tends to be totally the
responsibility of the programmer.

this is compounded by the fact that source buffers have a length
paradigm based on data pattern within the buffer ... aka i've seen
programmers who get into the habit of relying on the source buffer
having an implicit length. this comes into conflict with two different
length paradigms ... source length paradigm is self-describing and
target length paradigm is totally programmer responsibility.

the past analogies are motor vehicle accidents ... there are lots of
ways to have motor vehicle accidents ... but infrastructure tends to
look at the most common and create countermeasures for them.  In 1999,
the statistics were that half the exploits were because of buffer
length related issues ... last year the percent seemed to drop to
possibly 20 percent ... not because the buffer related problems have
gone down ... but that some other types of exploits have increased

now, one analogy of having two separate buffer length paradigms at
work in a single environment ... source buffers tending to have length
caracteristics as part of the data and not normally programmer
specified ...  and target buffers having length paradigm that is
totally the responsibility of the programmer ... would be to have two
different driving conventions ... on even days ... people are to drive
on the right and on odd days ... people are to drive on the
left. Certain types of conventions can be shown to increase the
frequency and probability of mistakes (one is having multiple
conventions related to the same characteristic).

Now, in the past, there have been suggested that only people who don't
have accidents be allowed to drive. However, in reality, there are
some compromises ....you do try and get the drivers that are
excessively accident prone off the roads, but at the same time,
conditions that appear to contribute to frequency of accidents are
monitored and attempt is made to create countermeasures for things
that appear to be significant accident contributing factors.

I would suggest that the probability of mistakes in some other
programming environments (which don't even have to be implicit part of
the language ... but could be assembler where there is a consistent
length paradigm) is lowered when there is a single consistent length
paradigm for all buffers ... both source and target. There are some
further advantages when there is a single length paradigm AND many
opportunities for human mistakes are eliminated ... i.e. the
underlying infrastructure facilities take on some amount of
length/bounds responsibility.

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

X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: X68-64 buffer overflow exploits and the borrowed code chunks exploitation technique
Newsgroups: sci.crypt
Date: Fri, 07 Oct 2005 21:01:28 -0600

from previous threads on buffer overflow
http://www.garlic.com/~lynn/subintegrity.html#overflow

one of the posts from start of the year (in thread that starting nearly
a year ago) .... one of the refs. i mentioned from just published
article in linux magazine
http://www.garlic.com/~lynn/2005b.html#20 [Lit.] Buffer overruns

Oct. 2005 C/C++ Users Journal has article, Managed String Library for C,
pg. 30

Many of the vulnerabilities in existing C code ... because these
functions are standard, they continue to be supported .... often
to detrimental effect.

.. snip ..

my assertion that it is more than just an issue of the library
routines ... it can also be viewed as an issue that the data-pattern
based length paradigm ... is an incomplete paradigm ... since the same
paradigm can't also be used for areas that don't contain any data
... and that fewer mistakes are made when there is a single standard
paradigm for treating a construct (and can be considered separate
from the issue of standard system routines providing uniform and
consistent support for the paradigm).

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

IEH/IEB/... names?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IEH/IEB/... names?
Newsgroups: alt.folklore.computers,bit.listserv.vmesa-l
Date: Sun, 09 Oct 2005 09:09:39 -0600

jeffj@panix.com wrote:

Perhaps you know the answer:
long ago I used IBM mainframes.
Utilities started with IEH, IEB, etc.
What were the rules for those prefixes?

I remember IEHLIST (list files) and IEBGENER (file copy).
Wasn't IEHBR14 the null program so the JCL's DD side-effects
could occur (such as file creation or deletion)?

trusty search engine turns up:
http://64.177.8.214/sitepages00/PrRefComponentID.html
other references from the above site
http://64.177.8.214/sitepages00/PrMainframeReferenceTop.html

when i did the resource manager, there was a new module that i named
DMKSTP (tv adverts in the 60s ... muscle cars and the line, the
racer's edge)

misc. past posts mentioning dmkstp
http://www.garlic.com/~lynn/94.html#2 Schedulers
http://www.garlic.com/~lynn/2001e.html#51 OT:  Ever hear of RFC 1149?  A geek silliness taken wing
http://www.garlic.com/~lynn/2003.html#20 vax6k.openecs.org rebirth
http://www.garl