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

[Johnny Billquist]

RMS kept the idea alive in Emacs, where even today you fire up the core 
system, load all kind of libraries, and then you do a memory dump, which 
is the runnable Emacs image.

   JOhnny

On 2021-11-12 16:06, Thomas DeBellis wrote:
> 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.
>>>

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol