A dropfile is exactly what essentially Charles Duffy said, **a complete serialization of a process'** state. Important detail to be added: _Issued by the OS_. Essentially a recording of all states of a process to a disk file. Depending on the OS this includes - Registers - Allocated Memory Content - OS Values like - Assigned Devices - File Tables - Job Stack (*1) In some degree it's much like a dump, except written to file and reloadable. Main reasons for a dropfile to be written is either processing timeout (assigned total CPU time or run time exhausted) or an operator issued abort - like when needing space to load a different job. While dropfiles went quick out of use (see below) and being replaced by virtualization for commercial mainframes, they kept a major thing on scientific mainframes. CDC's operating systems were based around dropfiles. There was a whole set of utilities to handle dropfiles, especially to move them beteen production environment and development. To understand this it's important to keep in mind that these machines were about number crunching, not data processing. Here any addition of virtual memory meant slowing down the machine, so they worked without such fancy stuff (see [this answer][1] about Cray machines) . Also they (often) got a fixed number of processes that could run concurrent, defined by the number of 'PCs'. Processes got fixed amount of memory assigned as well as a total run time. Process was expected to work full time, not much I/O at all - after all, that's what a supercomputer was for: Crunching numbers. Such jobs needed the whole attention of a machine - and having the ability to operate more than one program at the same time at high speed was a major USPs of Cray's designs. If the assigned run time was reached, a dropfile got written, memory freed and its PC assigned to the next job in line. Usually a job was not expected to reach that limit, but this ofc depends on the way jobs were structured. There was no automatic restart, it was always done manual - after all, that job already exceeded what was assumed to be the time needed. So there must be something wrong. Tools (like `SWITCHP` on VSOS (*2)) allowed developers to load a dropfile to do a 'live' system diagnosis. Of course, researchers quickly learned about the benefits for their 'private' projects. Stuff were they didn't get enough processing time was lined up at very low priority, having the operator (or operator scripts) restating their job whenever there was no other to run. Dropfiles are a quite efficient way to handle a few jobs with long run times and low exchange rates. Compared to virtualization run time overhead is negliable. **So while dropfiles are related to virtualization, they are part of a complete different view on computer operation. They existed in environments that tried to avoide the overhead of virtual memory. In some degree they are related to checkpoints.** --- **Checkpoints** are a somewhat similar concept developed prior to dropfiles and persistent in commercial operation way into the 90s. Where dropfiles capture the whole process state for an automated and complete restart, checkfiles keep 'only' data (pointers) enabling continued operation after the application is loaded again. Here a process can request a 'checkpoint' written with data it needs for an optional restart. An OS managed one checkpoint file per process (if requested), whenever a new checkpoint was written the prior was deleted. Unlike with a dropfile, restarting from a checkpoint required cooperation of the program to be restarted. The job got started again as with the prior run, but the progam checked for a checkpoint and, if present, read it and prceeded. The whole operation is much like what modern office software (like Libre Office) does when being started after a crash. --- *1 - No, that's not a CPU stack, but the commencing punch card job - today's analogy would be 'the script' :) *2 - Which in fact as based on virtual memory operation - still the job structure was still based around long running batch operation. [1]: https://retrocomputing.stackexchange.com/questions/7737/did-cray-computers-use-virtual-memory/7739#7739