Submit to Batch, or Run Interactively?

From: Eric Lehti To: All

Do you have a rule of thumb you use in deciding whether to run a job interactively or on a job queue?

I read somewhere that a job that ties up your terminal for three to five minutes (with a priority 20 in QINTER), is equivalent to the cost of submitting it to run from a job queue at priority 50. The explanation was that job initiation sucks up some system resources, so you may as well run it interactively. Another source said 40 seconds is a good rule.

How many seconds or minutes do you feel is a reasonable length of time to tie up a workstation running a job before you think you (and all other users on your system) would be better off submitting it to a job queue?

I find that the majority of users accepts that their report will process in the order received on the job queue. And I am converting more of our jobs to submit to the job queue. But now the job queue is getting stacked up with 20 to 30 jobs, at times.

The other day a user said, "I liked it better when the job ran attached to my workstation. I could always get my report in two minutes. Now I don't know how long I will have to wait for it." What suggestions do you have?

From: Paul Yust To: Eric Lehti

What we do is group our users by location. For each location, we have a different job description (i.e., LOCAJOBD, LOCBJOBD, ACCTJOBD, etc.) that is specified in the user profile. Each job description has a corresponding job queue (i.e., LOCAJOBQ, LOCBJOBQ, etc.). Finally, each of these job queues is added to the QBATCH subsystem. Each job queue entry for the subsystem is set up to allow one active job. The whole QBATCH subsystem is limited to four active jobs. This way, we can have up to four batch jobs active at a time.

You probably won't want to create more job queues than the maximum number of active jobs you allow to run from the QBATCH subsystem, since it would mean that when all job queues have jobs in them, some of them would not get immediate service.

From: John Brown To: Eric Lehti

I was told by IBM many years ago that if a job has no user intervention required (i.e., reports, batch file processing, etc.), then it should run in batch regardless of the time it takes to run. Now, in real life, I take each job on an individual basis, contingent on the resources required to complete it.

From: Michael Catalani To: Eric Lehti

It sounds as though you have migrated from a S/36, because you said your users liked having their reports run on the display station. I ran into the same problem all the time when I migrated S/36 shops. They were used to having their reports run on screen so they knew when the report finished.

There are some major performance reasons why you should not do this, but one reason most people do not know about is how the system actually handles interactive batch jobs. The system has some "performance algorithms" that will actually raise an interactive batch job's priority (numerically lower it) because it is I/O intensive. This will give that report program more priority than your true interactive users.

The best way to handle them is to submit them to batch. These reports may run slower until you get all of your "batch" work submitted. The best way to handle this depends on the size of your processor and the amount of memory you have. You can set up multiple job queues, but the number of batch jobs you should have active at a time depends on your processor speed and memory size.

If your processor is not running near 100 percent, then you have some processor time not being used. Therefore, you may be able to run more batch jobs. If it makes good business sense to run your report programs from the display station, then do it. In this case, use the Change Job (CHGJOB) command before and after running the program and lower the job's priority to 30 or 50. This will help keep it from competing with the interactive jobs.