Mohan and Jeff,
It's about time someone at HP realized the need for separate job queues!
However your solicition of
comments/suggestions should probably start at a higher level. The level of
detail in your document was far
beyond what is needed to solicit preliminary investigation feedback.
The objective of the job queues should be stated immediately after the
introduction. The focus should be
stated clearly. For Example:
Objective: The purpose of this project is to enhance the system manager's
ability to control the initiation
of job streams that are in the WAIT state. This can be used to ensure a
critical job is not prevented from
running by a less crucical job.
Some examples of job queues that I would set up would be:
System Jobs: SCOPEJOB, FTPMON, @.SYSMGR. @.HPOFFICE, Oracle's SQLNET job,
etc.
Production Drivers: Background jobs that an application requires to
fucnction.
Production Update jobs
Production Report Jobs
Development Check-out (Test) jobs
Development Compiles
Ad-hoc Report Jobs
Now for a little friendly critique of the Introduction Section of your
document.
>snip<
>Multiple Job Queues:
>-------------------
>
>Introduction:
>
>Presently MPE/iX has one job queue into which all the submitted jobs will
>go before getting launched by the dispatcher. Though users can submit
>their jobs into different subqueues within this single queue by specifying
>the Input Priority value in the :JOB command (this value can be anywhere
>between 1 and 13), <
Input Priority does not a sub-queue make.
>it is left to the user to specify it and if it is not
>specified all the jobs will go into the same subqueue (inpri = 8). Because
>of this, it is not possible to restrict a set of users from submitting
>jobs, so that any important jobs can have more CPU time, except by setting
>the Job Limit.
It is my understanding that the Threshold Manager has the responsibility for
specifying the amount of CPU a
job stream could get.
What you might say is that we need a mechanism to identify the jobs that we
wish to start executing sooner.
>
>To be able to selectively allow and disallow users from submitting jobs so
>as to be able to provide a better throughput for crucial jobs, it is
>necessary to have some mechanism of distinguishing between jobs of various
>users. To achieve this, we need to have multiple job accepting queues with
>the following properties.
>
<Big SNIP>
>=============================================================================
>Mohan Das K S email: [log in to unmask]
>HP India Software Centre Phone: 91-80-225-1554 x218
>29, Cunningham Road Telnet: 408-847-1026
>Bangalore - 560 001 INDIA Voice Mail: 408-447-4329
>=============================================================================
The rest of the document went into way too much detail (at least for a
preliminary investigation).
I would like to suggest adding a parameter to the :ALTJOB command ";HIPRI" that
would force a job to start
executing immediately (OP or SM cap. required).
Another note: Pertaining to the enhanced :SHOWJOB, divide the normal output
of showjob into the separate job
queses. My example follows:
:showjob q=system
JOBNUM STATE IPRI JIN JLIST INTRODUCED JOB NAME
QUEUE: System
#J11946 EXEC 10S LP WED 2:36A SUPRVISR,MGR.HPOFFICE
#J791 EXEC 10S LP TUE 9:46A EMG,MGR.SYSMGR
#J11949 EXEC 10S LP WED 2:40A MTRUCK0,MAILTRCK.HPOFFICE
#J11906 WAIT 10S LP WED 12:16A JGMISPL,MANAGER.SYS
CURRENT: 1/10/96 15:36
JOBNUM STATE IPRI JIN JLIST SCHEDULED-INTRO JOB NAME
#J12520 SCHED 8 10S LP 1/10/96 15:37 JRESPSLS,M590.ACCT1
#J12521 SCHED 8 10S LP 1/10/96 15:38 JRESPPLT,M590.ACCT1
2 SCHEDULED JOB(S)
QUEUE: System QLIMIT: 3 EXEC: 3 WAIT: 1 SUSP:0 SCHED:2
SYSTEM LIMITS:
21 JOBS (DISPLAYED):
0 INTRO
1 WAIT; INCL 0 DEFERRED
21 EXEC; INCL 0 SESSIONS
0 SUSP
JOBFENCE= 0; JLIMIT= 50; SLIMIT= 500
:
I hope you find this feedback useful.
Mark Ranft
General Mills Inc
[log in to unmask]
Standard Disclaimer: These idea(s) is(are) my own. Use at your own risk.
|
