JOB CLASS and priority question.

[Mukesh Chhabra]

What if two JOB's are submitted at same time by the same person

1.With same class and same priority
2.With different class and same priority
3. With different class and different priority

What happens if two Jobs submitted by different persons?
1.With same class and same priority
2. With different class and same priority
3.With different class and different priority

Can someone explain briefly?

[zum13]

Hello.

What controls when a job can run is the availability of a free initiator. The PRTY option is a way of prioritising which job gets the next free initiator. Who submitted the job doesn't come into the decision making, although it should be noted that the running job names need to be unique and where there are duplicates, only one will be allowed to run at any given time.

The initiators will have been configured by your sysprogs in the JES2 configuration. They are assigned to particular classes, so class "A" could have five initators and class "B" three. However, an initiator can also be assigned to multiple classes; there could be five initiators, three of which are shared between classes "A" and "B".

If you have a scenario where there are plenty of initiators for a particular class, then the priority isn't really an issue as each job will get an initiator as soon as it is submitted. It only comes into play where there is contention for the initiators, i.e. there are more jobs queued than available initiators to run them. Where priority is the same, the jobs will be run in submission order. If the priorities are different, the ones with the higher priority will run first.

So, if you have classes "A" and "B" defined with three initiators each and they are unique to each class, when an initiator on each class becomes free, the oldest job with the highest priority in each class will run next. A class "B" initiator becoming free could release a priority 6 job when there are priority 12 jobs sitting in the class "A" queue.

If class "B" is sharing its three initiators with class "A", then the next job to be submitted should be the oldest one with the highest priority in either class.

If class "B" shares two of it's initiators with class "A", but has one unique one, then the job that runs next will depend upon which initiator has just been freed. If it's a shared one, then class "A" and "B" jobs are eligible. If it's the unique class "B" one, then the oldest class "B" job with the highest priority should be the one to run next.

It is actually best to ignore priority completely. Some installations put restrictions on who can run jobs with non-default priorities, but you can also get into the situation in the work environment where noses are put out of joint because you're running higher priority and jumping the queue. If you wind up in the situation where everyone thinks the same thing and starts running their jobs with the highest priority the whole thing becomes meaningless and anything that really should have priority has to wait.