the process control block / process descriptor

If the operating system is a hospital running many patients (processes) at once, it needs a chart hanging at the foot of each bed - who this patient is, what they need, their current condition, who admitted them. The process control block is that chart: a data structure the kernel keeps for every process, holding all the bookkeeping the OS needs to manage that process and to pick up exactly where it left off after pausing it.

What lives in the PCB? At a glance: the PID and PPID; the saved CPU register values (including the program counter) so the process can be paused and resumed exactly; the current process state (running, ready, blocked, and so on); information about its address space (where its memory lives); its open file descriptor table; its credentials (user and group IDs); scheduling info like priority; and accounting like how much CPU time it has used. On Linux this structure is called task_struct. The kernel keeps these in a table or list so it can find any process by PID and switch between them. When the kernel pauses one process and runs another - a context switch - it saves the running process's registers into its PCB and loads the next one's out of its PCB.

Why it matters: the PCB is where a process really 'lives' from the operating system's point of view - it is the OS's complete record of one running instance. Almost every operation in this field touches it: fork() copies a PCB, exec() updates the parts that describe the memory image, wait() reads the exit status the kernel stored there, and scheduling flips the state field. You will rarely touch a PCB directly (it lives in kernel memory), but knowing it exists demystifies how the OS can juggle hundreds of processes and resume each one perfectly.