I'm not sure just plain core really counts, though (and of course I've used such systems), With anything I'd call persistent context saving, you can 'hibernate' system A, run something else on the machine, then (manually) return to running system A from the point at which you saved it.

@dave You seem to be using the term hibernation differently than anyone else - In a modern sense, a hibernated system can return to its saved state or initialize to its basic state (like a hibernated laptop), but the term does not imply you can do anything else between going to sleep and wake up (and still retain the hibernated state)

@dave jup, but such 'persistent saving' is more than a simple 'hibernating' and the later can be created as a sub case. I understand hibernating on itself being a more restricted case where a single setup gets saved an immediately restored. Like when windows saves itself to disk for power saving. Running something else inbetween is not permitted (by default). What I tried to show here is that the real history worked different to solve the issue. Simply extrapolating what is done today back to the 1960s doesn't create a linage.

@tofro With dual boot (Windows/Linux) PCs, it was possible to hibernate Windows, boot Linux, then return to the hibernated state in Windows.

Having persistent memory does not help if maintenance involves replacing a part of it. Application-assisted checkpointing is out of the scope of the question.

Having persistance on any storage media does not help if maintenance involves replacing a part of it.....

@LeoB. Maintenance replacing a memory core was an extreme rare event, even back then. Also, even storing to some non core media doesn't help if that drive or media got replaced, so the argument doesn't really work. More important, checkpoints were the solution back then for the reasoning you use (long running jobs that had to be suspended). Hibernation like today is a different solution to a different issue.

@tofro - in Windows, I can hibernate my Windows system, boot something else (say, from a USB key), and then later resume the hibernated Windows system. All hibernated state is held on the disk(s) of the Windows system. Don't confuse 'hibernate' to disk and 'suspend' which requires memory to be kept alive. With hibernate, you can power down.

@dave not really. At leas not as a windows feature. To boot something else you bypass windows by booting to another OS from BIOS. From Windows alone it's not possible (by default), thus loading another OS inbetween is not a feature of Windows hibernation, but the BIOS bootloader.

The appropriate analogy for old systems is switching the system disk pack. Or just booting a different pack from the console keyswitches.

@Raffzahn With removable disk packs, there was always a choice where to save the state of the system.

@LeoB. Except they were not always present. Think Drum or FD. Point is that there can always be a kind of 'maintenance that does not allow restoration, thus a change to system hardware cannot be used as ultimate argument for hibernation.

@Raffzahn Then, naturally, the question might not apply to those systems. Also, when the question is "Was the feature present in operating systems", responding with "In the beginning there was no OS" is useless. Whether the feature was saving the state of the whole system or unloading running jobs, mentioning the OS version and the year range the feature was introduced would be expected for the answer to be acceptable.

@LeoB. if it's a feature provided a hardware, then it comes with that hardware and needs no OS support - so no OS will add it. The question is a bit as useless as asking what was the first OS accepting keystrokes - a feature already there without an OS. You explicit ask for the 1960s mainframe market and that's where that functionality was provided even before OS as we understand today existed. Checkpoint functionality as well was not provided by OS but libraries/modules to be linked, again before any OS, thus mentioning some later OS version would not make any sense.

I don't get it. Which hardware provided saving state which could survive management running a higher priority job, you say? Aside: task checkpointing functionality provided by the OS was a thing; therefore it makes sense to ask who did it first. Dave's answer claiming that DEC RSX, or an earlier system, was capable of doing what I'm asking as an unintended way to pre-configure the system, looks more to the point to me.

To me, hibernation is specifically the concept of suspending state, copying said from volatile memory to non-volatile storage, and then being able to recover state in reverse. The ability to run something else between recovery is not guaranteed, as there are a lot of computers today which use a special power state for hibernation that will not let you load up a different OS.

@trlkly What's your point? If the ability to do what you mention plus the ability to run a different OS in-between was available first, are you saying that is should not be called "hibernation"?

My grandfather’s company owned an NCR 499 “accounting computer”, which had core memory. If the power went out, you could restart the program by punching in the right memory address, then pressing Execute.

This answer over-generalises. /Some/ mainframe computers used core for registers, but nit all: some even used delay lines (mercury or wire) which needed to be continually refreshed. And even those which used core for registers also had things like a microcode address register implemented using active devices.

@MarkMorganLloyd Sure, feel free to write a 300 page essay including the outliers :)). Also, of course were intermediate data held in some latches and counters. That's why stopping always occurred at instruction boundaries.

@LeoB My point is that clearly being able to run a different OS in between is not a requirement for hibernation, as it's still called hibernation when you can't do that.

@trickly Even without that requirement, and with core memory, the OS must have had a special provision to save volatile registers somewhere upon a request for hibernation, and to provide for a special execution path upon reboot after a power-cycle or some such, which would restore the registers. The question which OS was the first one to have that functionality still stands.

@LeoB. A /360 did not need any special store, as all registers were already in core. Likewise no volatile (like micro program counter) had to be restored, as stopping the machine only happened at the end of an instruction, which means that all of them are simply zeroed. And since the registers were already were they belong, no restore necessary either.

@Raffzahn Are you saying that stopping the machine, then powering it down for the holidays, then powering it back on and pressing the "go" button, or its equivalent, would just work, as if nothing has happened? If so, then good; /360 did not need OS support for hibernation, and therefore is out of scope of the question. Which was the first OS supporting running on a platform which needed OS support?

@LeoB. That's exactly how it worked.