[HECnet] RSTS/E started emitting "?EVTLOG (BLDNIC) -- %Integer error" messages

[Thomas DeBellis]

It's not uncommon or it least it didn't used to be.  Here are three 
examples:

First, I believe early versions of Smalltalk did exactly this.

Second, at WPI, we implemented two commands called freeze and thaw, 
which would take all the information in the currently running job (AC's, 
PC, open files, Etc.) and write them into a file.  You could ^C, freeze, 
come back later, thaw the .ICE file (frozen job, get it?) and be right 
where you were.  One common use was when a dial up was abruptly 
disconnected by call waiting.  The monitor would notice you were 
detached and perform a freeze on your behalf, thus both freeing up the 
job slot and not losing your work.  Saved me a bunch of TECO'ing.  It 
could have been extended to batch jobs running out of processor time, 
but I don't remember if it was.

I liked it so much that I tried to implement it at Columbia for 
Tops-20.  Tried...  I think the problem I ran into was that I couldn't 
find out timers and get the same fork handles.  Or one of the problems.  
Another was security, which I'll discuss below.

Third, at Columbia, it was used extensively in our chronically CPU 
starved environment:

  * The EXEC could save the PCL environment (but I think this originally
    was part of the CMU implementation)
  * The mailing system keeps a binary file of forwarding bindings.  If
    you edit the text source, the newer write date is noticed and the
    binary is 'recompiled'
  * I lifted the feature for LPTSPL's LPFORM.INI parser when I realized
    how often it was getting reparsed (basically after any idle period
    between jobs)

 From the information security standpoint, you have to consider the 
usage of these kinds of files.  Obviously, you wouldn't want to thaw 
something with JACCT set unless the existing job had the ability to get 
that, was [1,2] without some fairly careful checking.  Ditto Tops-20, if 
the fork had capabilities.  I mean, if somebody could get write access 
to the binary, then they could potentially compromise system security 
with a little strategic FILDDT'ing (or EXAMINE and DEPOSIT, if it came 
to that).

A 'legitimately' corrupt binary could also crash the fork on start up, 
but I don't recall as we ever fully addressed that.  I think a checksum 
would have been the obvious start, but I guess we didn't want to spend 
the cycles.

In these days of multi-gigahertz processors, I don't see the children 
discussing it much at all.

> ------------------------------------------------------------------------
> On 11/12/21 9:24 AM, Paul Koning wrote:
>
> That's a bit like how RSX-11/D and IAS boot -- by reloading the image 
> of memory when you issued the SAV command. Pretty clever: you set 
> things up the way you want them to be, and then you make that state 
> persistent.
> 	paul
>> ------------------------------------------------------------------------
>>
>> On Nov 11, 2021, at 6:22 PM, Johnny Billquist <bqt at softjar.se> wrote: 
>> I must admit that I hadn't considered the possibility of just saving 
>> the core. Which of course can accomplish the same thing in a neat way.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sonic.net/pipermail/hecnet-list/attachments/20211112/01ce4c46/attachment.htm>