[EMAIL PROTECTED] wrote:
The story I heard was they liked ASP, but it was too piggy so a
furious rewrite was undertaken and it became Half ASP. Most of the
design objectives were met. When they went to present, it was deemed
unsophisticated and changed to Houston ASP.
Local Houston branch office group put out HASP type-III for some time
before their was an official support formed in gburg and many of the
people moved there ... and the name change to JES2
ASP was two-processor loosly-coupled system ... although there was a
flavor called LASP (single processor) ... local-ASP somewhat to compete
with HASP.
both HASP and ASP come out of the field since the original "spooling"
built into the base product had significant issues.
My wife served a stint in the gburg group ... and was one of the
technology catchers for ASP ... when it was also moved to the gburg
group and renamed JES3. She also did a detailed technology and market
analysis of JES2 and JES3 for a proposal for a merged product
(maintaining the major important customer requirements from each in the
merged product). However, there was some amount of discord for that to
ever succeed. She did get quite a bit of experience regarding
loosely-coupled operation and was eventually con'ed into serving a sting
in POK in charge of loosely-couple architecture. She developed
peer-coupled shared data architecture ... that also saw quite a bit of
resistance. Except for work by the IMS hot-standby effort, it didn't see
much uptake until parallel sysplex
http://www.garlic.com/~lynn/subtopic.html#shareddata
lots of past postings mentioning HASP
http://www.garlic.com/~lynn/subtopic.html#hasp
I can almost see the cover of my old HASP documentation ... but I can't
remember the HASP type III program product number. However, search
engines are your friend; an old JES2 posting from 1992 giving some of
the original history and the type-III program product number:
http://listserv.biu.ac.il/cgi-bin/wa?A2=ind9204&L=jes2-l&T=0&P=476
following take from above:
"It was originally written in Houston in 1967 in support of the Appolo
manned spacecraft program. Subsequently it was distributed as a Type
III program, picked up a small number of users but through the years the
number of users have increased fairly substantially. Further more there
is a continuing demand today for HASP. The growth that we have
accomplished has not been without problems. In 1968 IBM decided that in
release 15/16 since we had readers and writers we no longer had a
requirement for HASP. IBM came down very hard on the users and said we
were'nt going to have a HASP. The users resisted and HASP exists today."
Any typos in the above are mine. My Contributed Program Library
document for HOUSTON AUTOMATIC SPOOLING PRIORITY SYSTEM 360D 05.1.007 is
dated August 15, 1967. The authors listed are: Tom H. Simpson, Robert
P. Crabtree, Wayne F. Borgers, Clinton H. Long, and Watson M. Correr.
... snip ...
One of the internal problems with the JES2 NJE network was it
traditional networking paradigm and severe limitations. Quite a bit of
the original code still carried the "TUCC" label out in cols. 68-71 of
the source. It had intermixed networking related fields in with all the
job control header fields. It had also scavange the HASP 256 psuedo
device table for network node identifiers; as a result a typical
installation might have 60-80 psuedo devices leaving only 180-200
entries for network node definitions. By the time JES2 NJE was
announced, the internal network was already well over 256 nodes.
http://www.garlic.com/~lynn/subnetwork.html#internalnet
The lack of strongly defined layers and intermixing networking and job
information severely compromised a lot of the internal network. Minor
changes to header format from release to release would result in network
file incompatibilities. Some machines somewhere in the world, upgrading
to a newer release before all the other machines in the world
simultaneously upgrading to the same release. There is the well-known
legend of the JES2 systems in San Jose being upgraded which resulted in
MVS systems in Hursley crashing trying to process network files
originating from the San Jose system.
the original internal network technology had been developed at the
science center (same place that gave you virtual machines, gml, and a
lot of interactive computing)
http://www.garlic.com/~lynn/subtopic.html#545tech
and had well defined network layering as well as effectively a form of
gateway technology in each of its nodes. I've frequently asserted that
heavily contributed to the internal network being larger than the
arpanet/internet from just about the beginning until possibly mid-85.
Because of the many limitations in NJE ... JES2 nodes tended to be
restricted to end-nodes in the internal networks. all the intermediary
nodes were the responsible of the networking technology from the science
center. When talking to a JES2 system ... a special NJE driver would be
started. The ease of having lots of different drivers all simultaneously
running in the same node ... also gave rise to the not only having a
large library of different NJE drivers ... that corresponded to all the
currently deployed JES2 releases. The other technology eventually
developed in these drivers was a canonical JES2 header representation.
The specific NJE driver directly talking to a real end-node JES2 system
would do an on-the-fly translation from the canonical format to the
format specifically required by the JES2 system it was talking to (as a
countermeasure to JES2 mis-understanding NJE header fields resulting in
MVS system crashes).
... for slightly other drift
one of the principle HASP people went to Harrison in westchester country
and started a project codenamed RASP. This was sort of a cross between
tss/360 and MTS ... reborn and redone from scratch as brand new
operating system. tailored for virtual memory environment and not
carrying with it all the baggage of real memory heritage ... heavy
dependency on pointer passing, application API still real address i/o
oriented with heavy dependency on ccw translation. a couple recent posts
on ccw translation
http://www.garlic.com/~lynn/2006.html#31 Is VIO mandatory?
http://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
http://www.garlic.com/~lynn/2006b.html#25 Multiple address spaces
http://www.garlic.com/~lynn/2006f.html#5 3380-3390 Conversion -
DISAPPOINTMENT
for various reasons that person eventually left and became an Amdahl
"fellow" in Dallas and started a project similar to RASP that was code
named Aspen. Along the way there was some legal wrangling regarding
whether Aspen was contaminated with RASP code. misc. past posts
mentioning RASP and/or Aspen.
http://www.garlic.com/~lynn/2000f.html#68 TSS ancient history, was X86
ultimate CISC? designs)
http://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86
ultimate CISC? designs)
http://www.garlic.com/~lynn/2000f.html#70 TSS ancient history, was X86
ultimate CISC? designs)
http://www.garlic.com/~lynn/2001g.html#35 Did AT&T offer Unix to Digital
Equipment in the 70s?
http://www.garlic.com/~lynn/2002g.html#0 Blade architectures
http://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do
we need it?
http://www.garlic.com/~lynn/2004q.html#37 A Glimpse into PC Development
Philosophy
http://www.garlic.com/~lynn/2005p.html#44 hasp, jes, rasp, aspen, gold
http://www.garlic.com/~lynn/2005p.html#45 HASP/ASP JES/JES2/JES3
http://www.garlic.com/~lynn/2005q.html#2 Article in Information week:
Mainframe Programmers Wanted
http://www.garlic.com/~lynn/2005q.html#26 What ever happened to Tandem
and NonStop OS ?
http://www.garlic.com/~lynn/2005q.html#27 What ever happened to Tandem
and NonStop OS ?
http://www.garlic.com/~lynn/2006b.html#24 Seeking Info on XDS Sigma 7 APL
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
