When job A wants to do I/O, it tells the OS of its intentions and in effect says, "Here is what I need done. Now do it for me." User programs are never allowed to directly read or write hard disks so that various security measures can be enforced. The OS then schedules the I/O operation, possibly making it wait until another job's operation is done. When it is possible to go ahead, a controller gets the command and takes over from there. By this time, the main computer has put job A into suspended animation and has started working on B's program. A's code and data remain in memory although the CPU is not doing anything to them right now. After a long while (long as far as the computer goes but much shorter than a blink of an eye.) the I/O controller announces that it has successfully read or written the data and A must be restarted. The way the controller announces this is usually by sending an interrupt to the main CPU, sort of electronically tapping it on the shoulder. After more bookkeeping, the CPU marks job A as ready to run and when program B has reached its own I/O operation and must be put to sleep, the CPU lets A actually start up again where it left off. To be fair to user jobs, many OS's use what is called round robin scheduling, which lets every waiting program have a crack at the CPU before going back to the first job.

This, in a nutshell, is how most multi-user operating systems work. There are of course a million and one permutations of details but even personal computers are getting these kinds of systems. Windows 95 and MacOS 8, for example, are full pre-emptive multi-tasking systems.