This is one of many jokes and humorous articles I collected, mainly from USENET and similar
sources in the early to mid 1990s. They're really not very interesting nowadays.
(from DATAMATION, April 1975).
Many nanoseconds ago in a TSO queue in protected paging sets, a super
resource scheduler built his control blocks. His most valued
possession was a flock of VS-UCBs. They gave comfort for reading,
writing and swapping as well as data for table lookups. And the
master scheduler activated them very carefully in foreground and
background under MVT, MFT and VS.
Often he took his young allocator to the rural registers where the
UCBs paused near Big Swap. The young allocator liked to go with his
master scheduler. He liked to play at start I/O time. When has was
inactive he chain linked from job stem to job stream that ran through
the bubbling memories.
One day his master scheduler queued the young allocator to load a
spool job from a waiting list and to play little tasks upon it. Many
cycles passed and one sunny nanosecond the master scheduler said to
his young allocator: "You are old enough to activate the page sets now
and there are other tasks about the mainframe that I should do. Go
with them to the rural registers and activate them as I have queued
you to do.
At first the young allocator enjoyed taking care of the flock of UCBs.
He kept the fluffy buffers from straying and found new memories when
the get/puts and filled all the available areas with data. To vainly
display himself, he made up dummy requests to fill his task list. But
after a while the work became tiresome and boring. "Here I am", he
mumbled, "with only UCBs for company. I'd like to hear the sound of a
modem voice once in a while, but all I hear is the silly deleting of a
flock of completed I/O seeks--Get. Put. Read. Write. Open.
Close." He complained to his monitor the master scheduler. "I am
tired of spending all my milliseconds with a silly flock of seeks".
"I am busy, young allocator", the master scheduler replied, "And there
is no else to send. For many 3rd generation cycles I have watched the
flock, but now because of virtual capacity there are working sets
which need attention. In a few releases your brother accessors will
be old enough to activate as you are now. For the present there is no
one except you with whom I can trus the UCBs".
The young allocator felt ashamed. He knew how hard his master
scheduler had worked to give his family a large capacity storage and
enough bytes to keep from swapping out. So he tried hard to take an
interest in the I/O seeks and for a time he was content.
Then he began to feel sorry for himself again. "No one ever queued
such a stupid list as mine", he thought. "I wish a poisson arrival
would come from the network. That at least would give me a little
excitement". Then an invalid parity check came into his status.
Sproing. Glitch*.Zap$... "The channel schedulers will heed me if I
BLEEP", he said to himself, and raising his ID he interrupted, "Help.
Help. Wild Device. Wild Device." The schedulers instantly came
masking with spare buffers and status words, but when they reached the
rural registers, of course there was no wild device. The young
allocator told them that the device had returned to normal. Some of
the schedulers doubted him, but a few felt sorry for the I/O seek
herder and linked to him for the rest of the shift.
A few days later he decided to try the same stunt again. He stuffed
an invalid parity bit into his status and was ready. "Help. Help.
Wild Device. Wild Device." He interrupted, and again the channel
schedulers came to his aid along with some main circuits. This time,
however, the few who had been so friendly earlier were suspicions when
they again foud that there was no wild device. "If there had been a
wild device here", said the main logic unit of the chief processor's
office, "there would have been some trace of his data stream in the
device controller's log". The young allocator pointed to some loose
bits and bytes in response, but the arithmetic unit said they had been
left by the double precision registers from their last parade and not
by the device. No one linked to the young seek herder this time, and
as they went back to their work the schedulers were extremely angry.
"I believe that that young allocating I/O seek herder is deceiving
us", said a sysgen job handler. "I'm sure of it", another agreed.
"If hi bleeps to Interrupt again", said the look-ahead register, "let
us pay no attention him. We'll just let his wild device toss its bits
upon the deaf ears of the excess bit mucked and make him start his
tasks over again".
A few days later a wild device really did send invalid parity bits
into the young allocator's frightened status and exploded into the
middle of its close macro destroying all chance for control. "HELP.
HELP. WILD DEVICE. WILD DEVICE. HELPPP..." The young I/O seek
herder interrupted in terror, for he had nothing but an old device
busy status word to use as an attention getter, and he knew that he
could not overcome such a huge wild data cell with just a busy signal.
The channel schedulers paid no attention to his cries for interrupt
but went about their business. The young allocator started to load
data beyond all reasonable bounds, attempting to interrupt all the
way. When he came to the main registers and the chief processors, he
found the main logic unit standing at the head of his queue. "Why did
you not swap when I bleeped?", the youngster demanded. "A great wild
data cell came and clobbered several of my seeks and gobbled up all of
my UCBs and even disabled my access module". "I am sorry to hear
that", the diagnostic logic unit replied, "but you had deceived us
twice and we calculated to the 13th decimal place that you were
deceiving us again. If you want help when you are in need, you must
call for that help only when it is necessary". No one believes a liar
even when he speaks with even parity.
