Author: steve-myers
Posted: Fri Apr 06, 2018 8:37 am (GMT 5.5)
As one level, Mr. Sample is correct, but he is simplifying the situation.
In MVS, there are three priorities
The second priority is pretty much determined by MVS workload management. A user job cannot alter or influence the priority. I don't really know if a user job can even determine what it is. MVS workload management attempts to maximize system operation based on rules defined by the system programmers. Roughly 30 years ago, IBM decided
The third priority can be influenced by the user program. The only time this matters is when when the program is operating subtasks. In 50 years I've only tried this once, and I never knew if it mattered. I ran several subtasks. Most of the time each subtask was I/O bound, but there were periods when it was CPU intensive. Just before a subtask went CPU bound I dropped its relative priority, and raised it when it went I/O bound again. Like I said, I never knew if it really helped.
Posted: Fri Apr 06, 2018 8:37 am (GMT 5.5)
As one level, Mr. Sample is correct, but he is simplifying the situation.
In MVS, there are three priorities
- A JES related workload selection priority.
- In MVS, an address space related selection priority that determines when an address space is selected for execution, relative to other address spaces.
- In MVS, when multiple tasks are running within an address space, a priority that determines the order in which the task is selected.
The second priority is pretty much determined by MVS workload management. A user job cannot alter or influence the priority. I don't really know if a user job can even determine what it is. MVS workload management attempts to maximize system operation based on rules defined by the system programmers. Roughly 30 years ago, IBM decided
- The system programmers were mostly incompetent to do this. I'm not sure I disagree.
- System activity changes too quickly for human intervention to make much difference. A human must determine there is a problem, figure out what can be done to correct the problem, and (hopefully) correct the problem. Here I agree.
The third priority can be influenced by the user program. The only time this matters is when when the program is operating subtasks. In 50 years I've only tried this once, and I never knew if it mattered. I ran several subtasks. Most of the time each subtask was I/O bound, but there were periods when it was CPU intensive. Just before a subtask went CPU bound I dropped its relative priority, and raised it when it went I/O bound again. Like I said, I never knew if it really helped.