ARMM: ARMM: >>>>Ad Infinitum
Joel Furr
>In article <tweekC4...@netcom.com> tw...@netcom.com (Michael D. Maxfield) writes:
>>>In article <AAAAAAAAAAAAAAAAAAAAAAAAA...@redpoll.neoucom.edu> r...@redpoll.neoucom.edu (Richard E. Depew) writes:
>>>>Automated Retroactive Minimal Moderation (tm) by ARMM5. Press 'n' to skip.
>>>>
>>>>*This* post carries the Supersedes header. It behaves just like the
>>>>Also-Control header with C-news, at least so far as I can tell.
>
>Er, maybe not, Dick.
>
>This brightens up my day... as soon as I can stop laughing and catch my
>breath for a second I'll tell all the programmers here about it... we're
>going to be cracking up about this for years to come!
In the sober light of day, I'm laughing as I re-read the comments on the
March 30 ARMM Massacre. Last _night_, on the other hand, I had a mental
image of a machine sitting atop a hill, making a low droning sound,
releasing infinite numbers of Frankenstein's Monsters on the surrounding
environs. Frankenstein's Monsters here, Frankenstein's Monsters there,
lurching about stiff-leggedly, arms outstretched, and all muttering the
same word over and over: ARMM ARMM ARMM ARMM ARMM.
Usenet History, I tell you. This needs its own listing in the Jargon File:
:ARMM: n. A USENET posting robot created by Dick Depew of Munroe Falls, Ohio.
Originally intended to serve as a means of controlling posts through
anon servers (see also {anon servers}). Transformed by programming
ineptitude into a monster of Frankenstein proportions, it broke loose
on the night of March 31, 1993 and proceeded to spam news.admin.policy
with something on the order of 200 messages in which it attempted, and
failed, to cancel its own messages. This produced a recursive chain
of messages each of which tacked on:
* another "ARMM:" onto the subject line
* a meaningless "supersedes" header line
* another character in the message id (producing message ids several
lines long)
* a ^L
This produced a flood of messages in which each header took up several
screens and each message id got longer and longer and longer and each
subject line started wrapping around five or six times. ARMM was
accused of crashing at least one mail system and inspired widespread
resentment among those who pay for each message they have downloaded.
Eric Raymond, you listening?
Lazlo Nibble
> In the sober light of day, I'm laughing as I re-read the comments on the
> March 30 ARMM Massacre. Last _night_, on the other hand, I had a mental
> image of a machine sitting atop a hill, making a low droning sound,
> releasing infinite numbers of Frankenstein's Monsters on the surrounding
> environs.
I had that same image *and* was laughing. If I was a drinking man, I'd
have turned up the Jackie Gleason CD and enjoyed a martini on the porch
with a self-satisfied grin smeared all over my face.
Cosmic justice is dreadfully entertaining.
--
Lazlo (la...@triton.unm.edu)
Eli Brandt
In article <1993Mar31....@mnemosyne.cs.du.edu> jf...@nyx.cs.du.edu (Joel Furr) writes:
[we need a Jargon entry]
Hey, a measly Jargon entry? I say this goes in with Mabel.
> This produced a flood of messages in which each header took up several
> screens and each message id got longer and longer and longer and each
> subject line started wrapping around five or six times.
So, does anyone have the Certified Largest and Hairiest ARMM Post?
I'd like a copy for posterity's sake, but the feed here doesn't seem
to have any with a full five wrappages.
This could serve as a litmus post for another current net.issue:
somebody send a copy in to rec.humor.funny. If Maddi doesn't find
*this* funny, we know it's time for a new moderator.
PGP 2 key by finger or e-mail
Eli ebr...@jarthur.claremont.edu
Eli Brandt
>Mabel?
Mabel the Swimming Wonder Monkey, killed in her prime. (I guess)
This tale of woe is actually not in the Folklore section, as I thought,
but under the entry for :scratch monkey:. So I guess an entry would
be sufficient...
You know, that should have been
alt.fan.dick-depew.armm.armm.armm
Mike Lazaro
> Originally intended to serve as a means of controlling posts through
> anon servers (see also {anon servers}). Transformed by programming
> ineptitude into a monster of Frankenstein proportions, it broke loose
> on the night of March 31, 1993 and proceeded to spam news.admin.policy
> with something on the order of 200 messages in which it attempted, and
> failed, to cancel its own messages. This produced a recursive chain
> of messages each of which tacked on:
>
> * another "ARMM:" onto the subject line
> * a meaningless "supersedes" header line
> * another character in the message id (producing message ids several
> lines long)
> * a ^L
>
> This produced a flood of messages in which each header took up several
> screens and each message id got longer and longer and longer and each
> subject line started wrapping around five or six times. ARMM was
> accused of crashing at least one mail system and inspired widespread
> resentment among those who pay for each message they have downloaded.
>
"Just between you and me, bub..." he whispered, "that's what we programmers
like to call an..."
Then he silently looked toward the heavens and called upon the power of
sysadmins long passed, the will of a thousand heroes, and that really mean dog
down the street that likes to eat innocent humans...and in a fit of rage,
yelled into the ears of the shadowy figure...
"AN INFINITE LOOP! DIDN'T YOU FIGURE IT OUT EVENTUALLY?? MY GOSH, MAN...
DIDN'T YOU TRY TO STOP IT? CONTROL-C!! CONTROL-C!! HAHAHAHAHA!!!"
And he ran off once again, back to his terminal, and back to his normal self,
leaving the effects of his latent inner personality to echo through the cables
of the network...
*****************************************************************************
My humblest apologies, but it seemed a keen subject for writing. I am truly
sorry, though I hope everyone enjoyed my short feature.
mike
Joel Furr
>In article <1993Apr1.0...@mnemosyne.cs.du.edu> jf...@nyx.cs.du.edu (Joel Furr) writes:
>>Mabel?
>
>Mabel the Swimming Wonder Monkey, killed in her prime. (I guess)
>This tale of woe is actually not in the Folklore section, as I thought,
>but under the entry for :scratch monkey:. So I guess an entry would
>be sufficient...
Oh, right. Dick should have mounted a scratch monkey before unleashing ARMM.
>You know, that should have been
> alt.fan.dick-depew.armm.armm.armm
ARRRGH! Damn, I wish I'd thought of that.
Jonathan M Lennox
> alt.fan.dick-depew.armm.armm.armm
No no no...
alt.fan.dick-depew
alt.fan.dick-depew.armm
alt.fan.dick-depew.armm.armm
alt.fan.dick-depew.armm.armm.armm
alt.fan.dick-depew.armm.armm.armm.armm
alt.fan.dick-depew.armm.armm.armm.armm.armm
alt.fan.dick-depew.armm.armm.armm.armm.armm.armm
alt.fan.dick-depew.armm.armm.armm.armm.armm.armm.armm
alt.fan.dick-depew.armm.armm.armm.armm.armm.armm.armm.armm
alt.fan.dick-depew.armm.armm.armm.armm.armm.armm.armm.armm.armm
alt.fan.dick-depew.armm.armm.armm.armm.armm.armm.armm.armm.armm.armm
etc...
We'd finally satisfy the people who complain that the
alt.foo.bar.bar.bar groups aren't real hierarchies...
--
Jonathan Lennox
jm...@cunixa.cc.columbia.edu
(NOTE: This is a joke! Do NOT really create these groups!)
Jeff DelPapa
>In article <1993Mar31....@mnemosyne.cs.du.edu> jf...@nyx.cs.du.edu (Joel Furr) writes:
>>
>>:ARMM: n. A USENET posting robot created by Dick Depew of Munroe Falls, Ohio.
>> Originally intended to serve as a means of controlling posts through
>> anon servers (see also {anon servers}). Transformed by programming
>> ineptitude into a monster of Frankenstein proportions, it broke loose
>> on the night of March 31, 1993 and proceeded to spam news.admin.policy
>> with something on the order of 200 messages in which it attempted, and
>> failed, to cancel its own messages. This produced a recursive chain
>> of messages each of which tacked on:
>>
>> * another "ARMM:" onto the subject line
>> * a meaningless "supersedes" header line
>> * another character in the message id (producing message ids several
>> lines long)
>> * a ^L
>>
>> This produced a flood of messages in which each header took up several
>> screens and each message id got longer and longer and longer and each
>> subject line started wrapping around five or six times. ARMM was
>> accused of crashing at least one mail system and inspired widespread
>> resentment among those who pay for each message they have downloaded.
>>
>
>"Just between you and me, bub..." he whispered, "that's what we programmers
>like to call an..."
>
Finally an excuse to dredge up an old joke...
Question: are all odd numbers prime?
mathametician: 3's odd and prime, 5's odd and prime, 7's odd and
prime, 9's -> No
physicsist: 3's o+p, 5's o+p, 7's o+p, 9's experemental error, 11's o+p...
engineer: 3 o+p, 5 o+p, 7 o+p, 9 o+p, 11 o+p,...
economist: 2's o+p, 4's o+p,...
programmer: 3's o+p, 5's o+p, 7's o+p, 7's o+p, 7's o+p...
<dp>
j...@cmkrnl.com
> "Just between you and me, bub..." he whispered, "that's what we programmers
> like to call an..."
>
> Then he silently looked toward the heavens and called upon the power of
> sysadmins long passed, the will of a thousand heroes, and that really mean dog
> down the street that likes to eat innocent humans...and in a fit of rage,
> yelled into the ears of the shadowy figure...
>
> "AN INFINITE LOOP! DIDN'T YOU FIGURE IT OUT EVENTUALLY?? MY GOSH, MAN...
> DIDN'T YOU TRY TO STOP IT? CONTROL-C!! CONTROL-C!! HAHAHAHAHA!!!"
Nah. An infinite loop, as the term is usually applied, would have generated
an unlimited number of messages from a single input. Or an unlimited number
of cancels from a single input. Or something like that.
That's not what happened here. This was more in the nature of recursion, with
the "stack" stored in the message itself. The result was a sort of a software
laser... an amplifier connected in positive-feedback mode.
Granted that both "unbounded recursion" and "infinite loop" involve executing
the same code over and over, but in unbounded recursion, some aspect of the
*data* is different each time... as it was here.
(A *true* software laser, involving *two* sites bouncing messages (and copies
thereof, and copies of the copies, ..., at each other, happened a few years
ago...)
--- Jamie Hanrahan, Kernel Mode Systems, San Diego CA
Internet: j...@cmkrnl.com Uucp: uunet!cmkrnl!jeh CIS: 74140,2055
Dik T. Winter
> >Subject: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: distribution "ARMM" repo
rt
>
We are starved here. We still do truncate Subject lines at 255 chars. So we
have at most:
> >Subject: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARMM: ARM
And we do not yet have the alt.fan.dick-depew newsgroup. ARGH
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland
home: bovenover 215, 1025 jn amsterdam, nederland; e-mail: d...@cwi.nl
Peter Gutmann
>(A *true* software laser, involving *two* sites bouncing messages (and copies
>thereof, and copies of the copies, ..., at each other, happened a few years
>ago...)
It's happened here too - a message had some sort of extremely broken header
when sent to the US, and was bounced back. Some misconfigured mailer and/or
the broken header then caused it to be resubmitted for transmission to the
US. It was bounced back. It was resent. Every time it was resent it
acquired another hundred bytes or so of header. By the time it was zapped
it was (supposedly) over a MB in size.
What makes this really scary is that the monopoly which controls NZ's
link to the outside world charges for email at the (then) rate of $50/MB,
and this message must have pinged back and forth many, many times to grow
to the size it was at when it was finally killed. I don't think anyone
ever dared to calculate the size of the bill the sender would have been hit
with....
Peter.
--
pg...@cs.aukuni.ac.nz||p_gu...@cs.aukuni.ac.nz||gutm...@kosmos.wcc.govt.nz
pet...@kcbbs.gen.nz||pe...@nacjack.gen.nz||pe...@phlarnschlorpht.nacjack.gen.nz
(In order of preference - one of 'em's bound to work)
-- Surgeon-General's Warning: Intel inside! --
Mike Lazaro
>> "AN INFINITE LOOP! DIDN'T YOU FIGURE IT OUT EVENTUALLY?? MY GOSH, MAN...
>> DIDN'T YOU TRY TO STOP IT? CONTROL-C!! CONTROL-C!! HAHAHAHAHA!!!"
>
>Nah. An infinite loop, as the term is usually applied, would have generated
>an unlimited number of messages from a single input. Or an unlimited number
>of cancels from a single input. Or something like that.
>
>That's not what happened here. This was more in the nature of recursion, with
>the "stack" stored in the message itself. The result was a sort of a software
>laser... an amplifier connected in positive-feedback mode.
>
>Internet: j...@cmkrnl.com Uucp: uunet!cmkrnl!jeh CIS: 74140,2055
Obviously, you didn't have to watch ARMM scroll across your screen thousands of
times reading news at 2400 baud in the middle of the night...;) Thus, my
infinite loop simile came into being...
I stand corrected, so I think I'll sit down now--
mike
Dan Hoey
> You know, that should have been
> alt.fan.dick-depew.armm.armm.armm
Given the ramifications of the recent escapade,
alt.fan.dick-depew.armm:armm:armm:
would be more appropriate. If you don't know why, look for
alt.fan.enya.puke.puke.pukeSender:
in the alt-config-guide FAQ.
Dan Hoey
Ho...@AIC.NRL.Navy.Mil
James W. Birdsall
>In <1993Apr1.1...@cmkrnl.com> j...@cmkrnl.com writes:
>
>>(A *true* software laser, involving *two* sites bouncing messages (and copies
>>thereof, and copies of the copies, ..., at each other, happened a few years
>>ago...)
>
>It's happened here too - a message had some sort of extremely broken header
>when sent to the US, and was bounced back. Some misconfigured mailer and/or
>the broken header then caused it to be resubmitted for transmission to the
>US. It was bounced back. It was resent. Every time it was resent it
>acquired another hundred bytes or so of header. By the time it was zapped
>it was (supposedly) over a MB in size.
A couple months ago, my system was involved in a three-point closed
loop. I noticed some mail queued up that I couldn't account for (I'm the
only user here, and I have few enough feeds that I can keep track of what's
going where and why). Checking the logs, I noticed that it was coming from
system A (name changed to protect the guilty) and going to B!A!news. I
decided that, based on the addresses, there probably wasn't a privacy issue
and there certainly was something fishy going on, so I looked at the
messages.
I found a hundred or so lines of header indicating that the message had
looped through me quite a few times. The content was some sort of
software-generated success message which I don't remember the details of
anymore. I determined that it wasn't my problem, sent a copy of a
representative message (there were a dozen or so looping) to the sysads
of A and B with an explanatory note, and deleted them. Fortunately both A
and B are local phone calls, so I wasn't out any money.
B and A also had some fun when B was setting up Smail3. The user/sysad
of B had configured smail so that his smart-mail site was A, and had attempted
to configure smail to use a UUCP routing file, but something about that part
failed. So, when he sent a message to C!somebody, this happened: smail
couldn't find the routing file, so it forwarded the message to
A!C!somebody. However, A knew that C was attached to B, so it forwarded the
message back to B!C!somebody. smail still couldn't find the routing
table...
He finally found out about the problem when the message reached the
hop-limit AND WAS RETURNED THROUGH ALL THE BOUNCES IT HAD TAKEN!
Oops. :)
--
James W. Birdsall jwbi...@picarefy.picarefy.com
Compu$erve: 71261,1731 GEnie: J.BIRDSALL2
"For it is the doom of men that they forget." -- Merlin
Eric S. Raymond
> Eric Raymond, you listening?
Sure am. This'll go in 2.9.13, as I just froze 12.
--
Eric S. Raymond <e...@snark.thyrsus.com>
Joel Furr
>In <1993Mar31....@mnemosyne.cs.du.edu> Joel Furr wrote:
>> Eric Raymond, you listening?
>
>Sure am. This'll go in 2.9.13, as I just froze 12.
Great. When's 12 gonna be released?
Andy Linton
|> What makes this really scary is that the monopoly which controls NZ's
|> link to the outside world charges for email at the (then) rate of $50/MB,
|> and this message must have pinged back and forth many, many times to grow
|> to the size it was at when it was finally killed. I don't think anyone
|> ever dared to calculate the size of the bill the sender would have been hit
|> with....
Just a little clarification about the "monopoly which controls NZ's link to
the outside world" and charging.
The figure of NZ$50/MB (which is around US$25/MB) is just plain horse shit.
The link across the Pacific from NZ to Palo Alto is charged back to each
institution that uses it at a rate of between NZ$2.50 and NZ$4.00 per MB during
the day and between 50c and 80c per MB at night.
Each institution is free to pass on costs/charge their users as they please.
Peter's university at one point may have been charging their users $50/MB but
that is not something forced upon them by the cooperative group, Tuia, which
runs the Pacific link. Incidentally, Auckland University are a prominent member
of this group and as far as I am aware support the charging mechanism that is
in place.
It's not even clear that the sender would have been responsible for the bill
anyway if the misconfiguration was not his or her fault.
Peter Gutmann
>In article <1993Apr2.1...@cs.aukuni.ac.nz>, pg...@cs.aukuni.ac.nz (Peter Gutmann) writes:
>
>> What makes this really scary is that the monopoly which controls NZ's
>> link to the outside world charges for email at the (then) rate of $50/MB,
>> and this message must have pinged back and forth many, many times to grow
>> to the size it was at when it was finally killed. I don't think anyone
>> ever dared to calculate the size of the bill the sender would have been hit
>> with....
>
>Just a little clarification about the "monopoly which controls NZ's link to
>the outside world" and charging. The figure of NZ$50/MB (which is around
>US$25/MB) is just plain horse shit.
I never said *which* monopoly, did I? :-) Anyway, if we're being hit with
a markup of between 1000 and 10,000% (according to your figures) we at
least have the right to grumble about it now and then.
>Incidentally, Auckland University are a prominent member of this group and
>as far as I am aware support the charging mechanism that is in place.
That's hardly surprising, considering the massive profits they're making
off it. Anyway, shouldn't this be in email, or at least nz.general (it'd
make a change from the current news censorship flamefest).
Peter.
--
pg...@cs.aukuni.ac.nz||p_gu...@cs.aukuni.ac.nz||gutm...@kosmos.wcc.govt.nz
pet...@kcbbs.gen.nz||pe...@nacjack.gen.nz||pe...@phlarnschlorpht.nacjack.gen.nz
(In order of preference - one of 'em's bound to work)
-- Nostalgia isn't what it used to be --
Dave Horsfall
j...@cmkrnl.com writes:
| (A *true* software laser, involving *two* sites bouncing messages (and copies
| thereof, and copies of the copies, ..., at each other, happened a few years
| ago...)
Yup - I've seen some myself. Many years ago, some newbie user set up
mail to forward to himself on another machine, but quite forgot that
the other machine was forwarding back again. And this was in the days
of before Sendmail (and loop detection)...
Another one involved two "service" accounts, set up to acknowledge whatever
mail they get (for subsequent batch processing etc). Some error somewhere
caused mail to be returned from one server to another. Oops...
--
Dave Horsfall (VK2KFU) VK2KFU @ VK2RWI.NSW.AUS.OC PGP 2.2
da...@esi.COM.AU ...munnari!esi.COM.AU!dave available
Lasse Hiller|e Petersen
jm...@cunixa.cc.columbia.edu (Jonathan M Lennox) wrote:
>
> In article <C4srn...@news.claremont.edu> ebr...@jarthur.claremont.edu (Eli Brandt) writes:
> >You know, that should have been
> > alt.fan.dick-depew.armm.armm.armm
>
> No no no...
>
> alt.fan.dick-depew
> alt.fan.dick-depew.armm
> alt.fan.dick-depew.armm.armm
> alt.fan.dick-depew.armm.armm.armm
> alt.fan.dick-depew.armm.armm.armm.armm
> alt.fan.dick-depew.armm.armm.armm.armm.armm
> alt.fan.dick-depew.armm.armm.armm.armm.armm.armm
> alt.fan.dick-depew.armm.armm.armm.armm.armm.armm.armm
> alt.fan.dick-depew.armm.armm.armm.armm.armm.armm.armm.armm
> alt.fan.dick-depew.armm.armm.armm.armm.armm.armm.armm.armm.armm
> alt.fan.dick-depew.armm.armm.armm.armm.armm.armm.armm.armm.armm.armm
> etc...
> (NOTE: This is a joke! Do NOT really create these groups!)
Perhaps we should ask Dick to modify ARMM to create newgroup messages?
:-) :-) :-) :-)
(Dare I post this, even with smilies? Dick might misinterpret my words
again. Dick: DON*T. DO. IT. THIS. WAS. A. JOKE.)
--
Lasse Hiller|e Petersen*las...@imv.aau.dk ! "Dick Depew ist noch mehr
Department of Information & Media Science ! Affe als irgend ein Affe"
Aarhus University, DENMARK ! -Nietzsche (sort of)
B.M. Buck
And when is the next edition of TNHD comming out? My current copy of
TNHD is confenient, easy to read, has a nice little bug in it's
pointers, but is only Jargon File 2.9.6! The last copy of the Jargon
file I snagged off the net was 2.9.10, but I still find TNHD more
convenient.
--
-----
Buddha Buck bmb...@ultb.isc.rit.edu
(insert-file ".disclaimer")
"I'm not an actor, but I play one on TV."
Joel Furr
>In article <1993Apr4.0...@mnemosyne.cs.du.edu> jf...@nyx.cs.du.edu (Joel Furr) writes:
>>In article <1l0NQj#5TsD416MX78C1NXFwz3GQ41j=e...@snark.thyrsus.com> e...@snark.thyrsus.com (Eric S. Raymond) writes:
>>>In <1993Mar31....@mnemosyne.cs.du.edu> Joel Furr wrote:
>>>> Eric Raymond, you listening?
>>>
>>>Sure am. This'll go in 2.9.13, as I just froze 12.
>>
>>Great. When's 12 gonna be released?
>
>And when is the next edition of TNHD comming out? My current copy of
>TNHD is confenient, easy to read, has a nice little bug in it's
>pointers, but is only Jargon File 2.9.6! The last copy of the Jargon
>file I snagged off the net was 2.9.10, but I still find TNHD more
>convenient.
Hmm. Good question, and one I'd like to know the answer of also. Eric
sent me a file when I wrote him to inquire about an FTP site for the
Jargon File that implied that additional printings of the book are an
option if it continues to sell well.
Eric S. Raymond
Any day now. I unfroze it due to a massive set of corrections and additions
by Steve Summit that came in the day I was planning to release. As soon as
I get these folded in, it'll go out.
Rodney Wines
> In article <1993Apr1.1...@cmkrnl.com>,
> j...@cmkrnl.com writes:
>
> | (A *true* software laser, involving *two* sites bouncing messages (and copies
> | thereof, and copies of the copies, ..., at each other, happened a few years
> | ago...)
>
> Yup - I've seen some myself. Many years ago, some newbie user set up
> mail to forward to himself on another machine, but quite forgot that
> the other machine was forwarding back again. And this was in the days
> of before Sendmail (and loop detection)...
I'm recalling the following story from memory, so I may screw up a
technical detail or two!
Back in the good old days of IBM 360's and maybe 370's, when _real_ men
could read Hollerith code and Teletype tape, there was this product called
HASP (or Houston Automatic Spooling Procedure). I think it was originally
developed for NASA Houston, but it was so much better than IBM's remote job
entry software (it could actually let you submit one job while another was
printing) that it got supported by Big Blue. Anyhow, the heart of this
thing was a HASP workstation. A HASP workstation could be just a dumb RJE
station, or a Big Blue machine. There were a lot of magic HASP commands
that you could send to a real computer along with the batch job.
Anyhow, what happened in the Triangle Universities Computation Center
(TUCC) network back in North Carolina in the '60's was that somebody
figured out how to submit a job to HASP which would in turn submit itself
to every hasp station on the network. If the receiving HASP station was a
dumb system, the job got discarded. If the receiving system was a smart
system, the job resubmitted itself twice! HASP had a unit called something
like "INTRDR" for "Internal Reader", which a program could use to spawn
another batch job. Primitive stuff by today's standards. A nice thing
about the internal reader was that if the spool space started to fill up,
the OS gave priority to the internal reader jobs in order to try to enpty
the spool space!
At the time, there was a large IBM system at TUCC, other smaller IBM
systems at N. C. State, Duke, and the University of North Carolina. I
don't know how many other smaller "mainframes" were scattered around North
Caroline.
The result of this was utter chaos. All the systems had to be shut down,
and their spool space completely purged before any of them could be brougnt
back up. This took quite a long time to accomplish, quite a bit of user
work was lost, and for some reason the internal reader wasn't available to
normal users anymore.
===================================================================
| Rodney Wines, Alcatel STR AG, | Phone: +41 1 465-2205 |
| Friesenbergstr. 75, CH-8055 Zurich | FAX: +41 1 465-2411 |
-------------------------------------------------------------------
| Internet: rodney...@alcatel.ch | "I always wanted roots, |
| X.400: c=CH a=arCom p=Alcatel | but if I can't have roots |
| s=Wines g=Rodney | I'll have wings." |
===================================================================
Lon Stowell
>
>Back in the good old days of IBM 360's and maybe 370's, when _real_ men
>could read Hollerith code and Teletype tape, there was this product called
>HASP (or Houston Automatic Spooling Procedure). I think it was originally
>developed for NASA Houston, but it was so much better than IBM's remote job
>entry software (it could actually let you submit one job while another was
>printing) that it got supported by Big Blue. Anyhow, the heart of this
>thing was a HASP workstation. A HASP workstation could be just a dumb RJE
>station, or a Big Blue machine. There were a lot of magic HASP commands
>that you could send to a real computer along with the batch job.
I have it on pretty good authority that the real reason IBM
sold HASP was to find something useful the 360/20 could do..as it
was slightly less powerful than the keyboard on a modern async
terminal. But it did make a decent print spooler.
Mark C. Lawrence
lsto...@pyrnova.mis.pyramid.com (Lon Stowell) writes:
>In article <1993Apr15....@srzts100.alcatel.ch> rodney...@alcatel.ch writes:
>>Back in the good old days of IBM 360's and maybe 370's, when _real_ men
>>could read Hollerith code and Teletype tape, there was this product called
>>HASP (or Houston Automatic Spooling Procedure). I think it was originally
It's the Houston Automatic Spooling *Program*
>>developed for NASA Houston, but it was so much better than IBM's remote job
>>entry software (it could actually let you submit one job while another was
>>printing) that it got supported by Big Blue.
It wasn't (and isn't) just remote job entry software; it was (and is) the
complete spooling system with job entry, and printing. It queues jobs for
execution and queues output for printing, based on output classes, and printer
attributes such as forms type, character set/print train, etc. There was a
spooling system on OS/360 before HASP, but it apparently was much less
flexible. (any of you oldtimers out there know about this original spooler?
I'd be curious...)
>>Anyhow, the heart of this
>>thing was a HASP workstation. A HASP workstation could be just a dumb RJE
>>station, or a Big Blue machine.
Not the heart at all. HASP runs on the main machine (btw, nowadays it's
called "JES2"). It allows jobs to be submitted from and/or printed at Remote
Job Entry (RJE) stations. These may in turn be specialized hardware boxes
(2780 or 3780 RJE station), or little /360 type machines (e.g. 360/30), or
"brand X" machines emulating 2780/3780), or other large machines.
> I have it on pretty good authority that the real reason IBM
> sold HASP was to find something useful the 360/20 could do..as it
This is absurd; HASP was used *on big mainframes* (and still is) because it
does a good job of handling input and print queues, etc. The RJE capability
is certainly valuable.
BTW, the alternative to HASP is ASP (Attached Support Processor, I think)
which originally used a dedicated medium-sized mainframe to support multiple
processor systems (i.e. several closely coupled mainframe systems). It
evolved into JES3. As always where there are two different ways to do things
in computing, the availability of these two rival systems has provoked
religious flamewars galore over the years.
> was slightly less powerful than the keyboard on a modern async
> terminal.
True enough, 360/20s went obsolete rather early...
>But it did make a decent print spooler.
I don't think you could use a /20 for a print spooler, it wasn't powerful
enough. It may have been usable for a very small RJE station, but i think /30s
were preferred for this. We used to have one here, it ran 2 card readers and
3 line printers, had no disk or tape (was IPL'd from a card deck).
Mark C. Lawrence
Systems Programmer Internet: M.Law...@Forsythe.Stanford.edu
Stanford Data Center Bitnet: M.Lawrence@STANFORD
Stanford, CA 94305-4136 Tel: (415) 723-4976
Rich Greenberg
>attributes such as forms type, character set/print train, etc. There was a
>spooling system on OS/360 before HASP, but it apparently was much less
>flexible. (any of you oldtimers out there know about this original spooler?
>I'd be curious...)
Never heard of one for OS prior to HASP. (And I go back to OS/360 PCP rel 3).
>BTW, the alternative to HASP is ASP (Attached Support Processor, I think)
>which originally used a dedicated medium-sized mainframe to support multiple
>processor systems (i.e. several closely coupled mainframe systems). It
The "global" could and usually did run a batch stream as well as
running the complex.
>evolved into JES3. As always where there are two different ways to do things
>in computing, the availability of these two rival systems has provoked
>religious flamewars galore over the years.
Ain't that the truth!
>I don't think you could use a /20 for a print spooler, it wasn't powerful
>enough. It may have been usable for a very small RJE station, but i think /30s
>were preferred for this. We used to have one here, it ran 2 card readers and
>3 line printers, had no disk or tape (was IPL'd from a card deck).
I don't think you could attach disks to the 20, making it hard to do
print spooling. I have seen 20s used as RJE stations with 2 or 3
printers and a card reader/punch. I don't remember if it had a console
of if you sent cards with commands and got the response back on a printer.
With the HASP distribution from IBM, there was a library of RJE programs
which you punched the member(s) coresponding to the computer(s) that
you had connected. These decks were IPL'd on the 20 or 30 running
stand-alone. There were also decks that you could run as a job
under OS or DOS after these systems had multi-tasking so one
partition did the RJE, and the other(s) ran local jobs.
--
Rich Greenberg Work: rm...@juts.ccc.amdahl.com 310-417-8999
N6LRT Play: ric...@netcom.com 310-649-0238
What? Me speak for Amdahl? Surely you jest....
Paul Vader
[Stuff about HASP omitted]
>It wasn't (and isn't) just remote job entry software; it was (and is) the
>complete spooling system with job entry, and printing. It queues jobs for
>execution and queues output for printing, based on output classes, and printer
>attributes such as forms type, character set/print train, etc. There was a
>spooling system on OS/360 before HASP, but it apparently was much less
>flexible. (any of you oldtimers out there know about this original spooler?
>I'd be curious...)
POWER on some 360/50s running DOS (no relation). It ran quite nicely in a
foreground partition (used something like 30K of the 256K of core storage the
machine had available). It was really fun to watch the card reader buzz through
a deck when the spooler was on, compared to the slow bursty mode you got when
some bozo forgot to start it at IPL.
>Not the heart at all. HASP runs on the main machine (btw, nowadays it's
>called "JES2"). It allows jobs to be submitted from and/or printed at Remote
>Job Entry (RJE) stations. These may in turn be specialized hardware boxes
>(2780 or 3780 RJE station), or little /360 type machines (e.g. 360/30), or
>"brand X" machines emulating 2780/3780), or other large machines.
(Job Entry System) package. It occasionally still burps out a message with a
HASP prefix to prove it. *
--
* PV But then again, I skate without deceased avians
Rich Greenberg
>Mark C. Lawrence writes:
>>Not the heart at all. HASP runs on the main machine (btw, nowadays it's
>>called "JES2"). It allows jobs to be submitted from and/or printed at Remote
>Try JES3, otherwise you're right. HASP was subsumed into the monstrous JES
>(Job Entry System) package. It occasionally still burps out a message with a
>HASP prefix to prove it. *
NO NO NO 1024 times NO.
Mark is correct. HASP evolved into JES2 and still has some of the original
messages. JES3 evolved from ASP, the Attached Support Processor.
Mark C. Lawrence
p...@gagme.chi.il.us (Paul Vader) writes:
>Mark C. Lawrence writes:
>>Not the heart at all. HASP runs on the main machine (btw, nowadays it's
>Try JES3, otherwise you're right. HASP was subsumed into the monstrous JES
>(Job Entry System) package. It occasionally still burps out a message with a
>HASP prefix to prove it. *
No, JES3 is ASP, JES2 is HASP. It is JES2 that still issues HASPxxxx
messages, I see them every day on the console.
More folklore questions here...HASP and ASP were apparently both developed
outside of the main OS/360 design groups. Neither seemed to get much
cooperation from the OS but were sort of grafted on top of it. For example,
HASP would modify your JCL so that, for example, SYSOUT=A [specifying a print
class for spooling] would become, say, UNIT=0CF [some 3-hex-digit unit
address] with the address being sysgenned as a printer but not physically
existing. HASP then would scan the I/O request queues for I/O's directed to
these units, intercept them, and spool the data. ASP used channel-to-channel
adapters (CTC), which looked to the system sort of like a tape drive. Some
bit of internal IBM politics/history here? The O.S. group liked its original
spooler, and didn't want any newfangled replacements?
At some point, IBM admitted defeat, canned the original spooler, and made HASP
and ASP official members of the O.S. "family", which is when they became JES2
and JES3. I suppose JES1 must be the original, extinct, spooler? At any rate,
this change also resulted in better interfaces to the O.S. (by now, MVS), and
gradual elimination of kluges like the fake unit addresses.
Joe Morris
>More folklore questions here...HASP and ASP were apparently both developed
>outside of the main OS/360 design groups. Neither seemed to get much
>cooperation from the OS but were sort of grafted on top of it.
> [discussion of HASP gimmick to trap spooled output] Some
>bit of internal IBM politics/history here? The O.S. group liked its original
>spooler, and didn't want any newfangled replacements?
ASP ("Attached Support Processor") was always a (supposedly) fully-supported
IBM product, what was then called "Type 1" (mainline system). In a lot
of environments it provided services that users needed, but it was always
subject to the bureaucratic problems of IBM officialdom. Whenever a new
OS release came out it seemed that ASP support for it was always several
months behind. It also was *extremely* resource-intensive.
HASP (see below) was written by Tom Simpson and his crew of maniacs in
the Houston IBM office completely outside of the normal IBM channels.
The program was distributed as a "Type 3" package (no "official" IBM
support, but not even in the 1960s was IBM so dumb as to refuse to
support its best-loved product). HASP was very tightly written, and
provided to MFT (and later, MVT) users the spooling functions which are
common on mainframe systems today, at amazingly low overhead. I was able
to fit a full MVS system plus HASP into a 512 KB system and still leave
256 KB for the users. (I knew that I would soon be adding more memory,
so this wasn't quite as odd as it might appear.)
HASP was always something of an oddity in the IBM system arena, with much
more personality in both the program and the support team than one usually
found in IBM. (For example, the crew came to a SHARE meeting once with
pictures of their "official" Volkswagen...it was, of course, a Type 3,
and was painted in the official HASP colors of orange and white, which
came from Tom's alma mater, the University of Texas.)
Oh yes, the etymology of "HASP": the official IBM party line is that
it stands for Houston Automatic Spooling and Priority system, but it's
common lore that it really is a comment on the relative sizes of the
"official" ASP and the "unofficial" HASP: Half-ASP.
Joe Morris