[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference noted::hackers_v1

Title:	-={ H A C K E R S }=-
Notice:	Write locked - see NOTED::HACKERS
Moderator:	DIEHRD::MORRIS

Created:	Thu Feb 20 1986
Last Modified:	Mon Aug 03 1992
Last Successful Update:	Fri Jun 06 1997
Number of topics:	680
Total number of notes:	5456

417.0. "Accounting for 'pending' jobs" by DPDSAL::EAGAN (Brendan Eagan /Dallas /451-2956) Tue Mar 03 1987 02:01

        I have a customer who is wrestling with the question of
        whether or not to buy an 8700.  (Buy, buy!)
        
        Part of the consideration is batch through-put.  They are
        concerned that batch jobs sit in the queues for a long time
        before they get processed.  Problem is  -- what is 'a long
        time.'
        
        There doesn't seem to be a mechanism w/standard accounting
        to determine how long a job is pending before it gets
        serviced.
        
        Any suggestions on how to do this?  Thanks.
    
                         [posted in VMSNOTES also...]

T.R	Title	User	Personal Name	Date	Lines
417.1	apples and oranges?	FROST::HARRIMAN	brouhaha..balderdash..ballyhoo	`Tue Mar 03 1987 14:03`	22
	but, I always thought that was a function of how many jobs are in the queue divided by what the queue's job limit is, along with the "load" of a job against the resources - (CPU, I/O)... I mean, if you have a job limit of 1 in your batch queues and 100 jobs sitting in the queue, accounting has nothing to do with determining whether or not to run jobs - they either get prioritized by the job controller or they run, one at a time.... setting the queue's job limit up to 6, for example, makes six jobs run at once - generally this causes more "throughput"... print queues don't work quite the same way as execution queues, you can set them up to either a) favor smaller jobs over longer jobs, or b) favor higher priority jobs over lower priority jobs. Also if the print job is bigger than the maximum block size allowed, the job sits in the queue until someone expressly releases it... true or false? /pjh
417.2	no, apples and apples	DPD01::EAGAN	Brendan Eagan /Dallas /451-2956	`Tue Mar 03 1987 17:14`	12
	The question is in regard to BATCH queues. Regardless of queue depth, CPU utilization, etc, the question still is "Is there a way to tell how long a batch job remained in the queue before it started processing?" The queue depths are large, CPU utilzation is nearly 100% across the cluster, etc. The customer is trying to do some threshold analysis and capacity planning. How long a job sat in the queue is just one of his metrics...
417.3	That wasn't what you said earlier	FROST::HARRIMAN	brouhaha..balderdash..ballyhoo	`Tue Mar 03 1987 18:13`	19
	That wasn't what I percieved the first time......... Oh. Well, the queue time information is kept by the job controller. You get that from $GETQUI (or show queue/full for you DCL fans)... The reason ACCOUNTING doesn't keep this normally is that the queued job isn't a process until it starts executing. You can, by the way, tell ACCOUNTING to write a USER accounting record via $SNDJBC. Anyway, once the job completes you lose the queue time since it gets purged from JBCSYSQUE.DAT....! Therefore it seems you need to write a utility or something to capture that information OR you can just write a application to $SNDJBC (submit) files for execution and have the files post their start and completion times to the same place. So there are ways to get this information IF you want to write an application.... /pjh
417.4	Here's one hack...	SWAMI::LAMIA	Cheap, fast, good -- pick two	`Wed Mar 04 1987 14:25`	19
	A quick 'n dirty way to get this is to set up SYLOGIN.COM to include something like this: $ (check if BATCH with f$mode) -- if so, then $ ASSIGN (some world-writeable dir/filename) SYS$OUTPUT ! make trace file $ SHOW DAYTIME ! when this is running now $ SHOW QUEUE/BATCH/FULL [batch-stream if known in advance, else nothing] $ DEASSIGN SYS$OUTPUT $ $ (continue) Later on, have some program read and parse all the trace files and produce a report of submit times vs. run start times. If you want to go to the effort of writing a program that uses $GETQUI, you can have it append the information records to a single sequential file that would make writing the reporting program a little easier. Doing it this way instead of writing accounting records bypasses messy details like having to install the logging program with privs., etc.