🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: alt.folklore.computers
Article #600

Re: The program that stumbled

#600
From: David Collier-Brown
Date: Sun, 24 Dec 1989 00:25
52 lines
2956 bytes
>I too, had a program that seemed 'stuck' on one address.
Alas, the address in question was zero, so its was reboot-time whenever
this occured. Real quick!

  I and two collegaues had been writing a program that ran stand-alone on an
IBM 303x (well, actually virtual standalone, we were using vm to debug it).
One of the things it had to do was dispatch interrupts, which on a /360 was
something of a giant pain.  Instead of writing the world's longest case
statement, we checked the manual for the supposed behavior of the channels
and sure enough, the channel control program counter pointed to the next
instruction after the end of the channel program.  So I decided that the
channel programs would:
	1) consist of single instructions
	2) not modify themselves, and
	3) be immediatly followed by the interrupt handler for that
	   program.
  This worked perfectly as we started single-stepping through the program.
The first interrupt came in, the common handler set up a frame and called
the address in the channel's pc, it ran, detected that this was the first
time the device (an input pretending to be a cardreader) had been called and
this was just a "acknowlege startup" interrupt, returned, did an RTI and
all was well.  Then I handed it a "card".  
	Reboot.  
	Trace it again, plant a breakpoint in the interrupt handler, hand it
a card.
	Reboot.
	Trace it AGAIN, plan a breakpoint in the common handler, hand it a
card, watch it pick up the channel pc and branch to it.
	Reboot.

  What!!!!!  I just saw it work properly. It branched to the correct
location:  Er... it branched to the pc, anyway... 

 Yes, it branched to the contents of the channel pc, which were zero. Thats
the cause of the reboot.
  It seems like the channel pc was never used under VM, DOS & MVS unless
there was an error, so it was never set by VM unless the interrupt was due
to an error, startup interupt or other unusual event.  If it was a
non-excepional i/o interrupt the channel pc was zeroed. To this day I don't
know if the bare iron would do the same thing: we never got time on a
stand-alone machine to try it.

  Ah well, I never liked the /3sickly, anyway.

--dave


-- 
David Collier-Brown,  | davecb@yunexus, ...!yunexus!davecb or
72 Abitibi Ave.,      | {toronto area...}lethe!dave 
Willowdale, Ontario,  | Joyce C-B:
CANADA. 416-223-8968  |    He's so smart he's dumb.
Technical Details
Message-ID: <5979@yunexus.UUCP>
Path: mbox-mo1.pugleaf.net!gmdzi!unido!mcsun!uunet!clyde.concordia.ca!jarvis.csri.toronto.edu!utgpu!utzoo!yunexus!davecb
References: <129578@sun.Eng.Sun.COM> <129587@sun.Eng.Sun.COM>

Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!gmdzi!unido!mcsun!uunet!clyde.concordia.ca!jarvis.csri.toronto.edu!utgpu!utzoo!yunexus!davecb
From: davecb@yunexus.UUCP (David Collier-Brown)
Newsgroups: alt.folklore.computers
Subject: Re: The program that stumbled
Message-ID: <5979@yunexus.UUCP>
Date: 24 Dec 89 00:25:57 GMT
References: <129578@sun.Eng.Sun.COM> <129587@sun.Eng.Sun.COM>
Organization: York U. Computing Services
Lines: 52
Posted: Sun Dec 24 01:25:57 1989
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit