Difference between virtual memory and job pool
The concept of “job pool” refers to a batch processing system, where jobs are queued to be executed when resources are available. The job pool contains both jobs that are currently executing and jobs that have been scheduled but are not yet being executed. Ancient computers (and some mainframes that are still in operation) worked this way. When a job is executing, it is fully present in memory.

Modern systems don't work that way. Computers that are big enough to run multiple tasks — even many embedded systems — have a memory management unit which translates virtual memory addresses to physical addresses, and the operating system uses that to move each page between memory and disk (this is called swapping or paging). This is an evolution from earlier multiprocessing systems: at first (before the MMU era) processes were swapped as a whole, but nowadays, if there isn't enough memory to fit all currently running processes, the operating system can swap out the parts of processes that aren't currently being used.

Systems designed for large non-interactive computations generally use job management even today. Swapping takes time; if the active processes require more memory than is available to run comfortably, this causes thrashing. To avoid this, job schedulers do use job pools, and arrange to start jobs, and possibly pause them, based on available resources. The system works on top of an operating system based on virtual memory, so once a job is paused it will naturally be swapped out as its pages in RAM are replaced by pages of active jobs.

(Note that job-based management is only marginally relevant to today's computing environment. I wouldn't set much store by a textbook that focuses on that in the 21st century. Virtual memory, on the other hand, is relevant to all but low-end embedded systems.)