Content deleted Content added
Tony Sidaway (talk | contribs) Expand somewhat. |
Tony Sidaway (talk | contribs) |
||
Line 10:
However this low-level scheduling has its drawbacks. A process that seldom needs to interact with peripherals or other processes would simply hog processor resource until it completed or was halted by manual intervention. This problem is resolved by allocating a "timeslice" to each process, a period of uninterrupted execution after which the scheduler automatically puts it on the sleep queue. Process could be given different priorities, and the scheduler could then allocate varying shares of available execution time to each process on the basis of the assigned priorities.
==Job control languages==
Early computer [[operating system]]s were relatively primitive and were not capable of sophisticated resource allocation. Typically such allocation decisions were made by the computer operator or the user who submitted a job. [[Batch processing]] was common, and interactive computer systems rare and expensive. Job control languages (JCLs) developed as primitive instructions, typically punched on cards at the head of a deck containing input data, requesting resources such as memory allocation, serial numbers or names of magnetic tape spools to be made available during execution, or assignment of filenames or devices to device numbers referenced by the job. A typical example of this kind of language, still in use on mainframes, is [[IBM]]'s [[Job Control Language]] (also known as JCL). Though the format of early JCLs was intended for punched card use, the format survived the transmission to storage in computer files.
As time sharing systems developed, interactive job control emerged. An end-user in a time sharing system could submit a job interactively from his remote [[computer terminal|terminal]], communicate with the operators to warn them of special requirements, and query the system as to its progress. He could assign a priority to the job, and terminate (kill) it if desired. He could also, naturally, run a job in the foreground, where he would be able to communicate directly with the executing program. During interactive execution he could interrupt the job and let it continue in the background or kill it. This development of interactive computing in a multitasking environment led to the development of the modern [[shell (computing)|shell]].
{{computer-stub}}
| |||