I fully agree with prior postings by Jerry Fochtman and Joseph Rosenblatt:
it depends on a number of things.  They both made a number of good
suggestions.

Generally speaking, there is not one hard and fast rule to follow regarding
this subject.  How you configure your batch processing & scheduling depends
on any number of things: CPU speed, size of main memory, the number of
volumes your data is spread across, how well your files are spread across
available volumes (clustering problems), whether the job(s) is(are)
CPU-bound or I/O-bound, etc.  As you can see, there are a lot of things to
consider.

Assuming your jobs are not CPU-bound, and assuming you are not trying to run
a zillion batch jobs at the same time, you will get greater overall
throughput by running multiple batch jobs simultaneously.

The primary reason this is true is that the CPU spends considerable time
"twiddling its thumbs", waiting for I/O to occur (be it disk or tape).  By
having two or more batch jobs running simultaneously you more effectively
use the CPU.  Individually, each job will probably take a bit longer (wall
clock) to finish, but collectively you will get more work done.

However, if you have too many batch jobs running at the same time you may
end up with the OS spending too much time doing what OSs do for a living -
managing memory (both real and virtual), disk, and allocating the CPU to
whatever processes are demanding time.  (Joseph mentioned this at the end of
his posting: "There will come a point of diminishing returns.")  As you add
an additional process (i.e., batch job) you add additional work for the OS.
For example, when the process makes demands for data or code, if the data or
code is not already resident in main memory, the OS has to fetch it from
disk.  The more processes, the more demands.  The more demands, the more the
OS has to do.  At a certain point you end up with the OS consuming vast
amounts of CPU and disk capacity simply paging stuff in and out of main
memory.  (In IBM parlance, this excessive paging activity was called
"thrashing".)  Fortunately, with the main memory capacities of today's
machines, excessive paging is a lot harder to achieve.  Not impossible, but
a lot harder.

Another often overlooked item is how your data files are spread across the
volumes, and how badly they are fragmented.  Normally you would like files
to be spread evenly across all available volumes.  This helps balance the
disk I/O load so that one or two volumes are not being hammered while the
others simply sit.  If your data files are being accessed sequentially,
having many extents will slow down your job(s).  However, if they are being
accessed randomly, having many extents may actually improve performance.
Jerry spoke of this in his posting: "Do you have/have you used any tools to
defragment and improve the condition of your disc drives and file extent
placement/sizes?"

Do any of these jobs do FCOPYs of large files?  If so, consider using
Suprtool, which is tons faster than FCOPY.  Also, if you FCOPY from, say, a
KSAM file to a sequential file, then sort the sequential file, consider
replacing the two steps (FCOPY and SORT) with one Suprtool step which reads
the input KSAM file, sorts it, then outputs it as the sequential file.  Not
only will you gain by replacing FCOPY with the much faster Suprtool, but by
including the sorting step in Suprtool you have to make only one pass
through all the records.  (That is, you eliminate the second pass through
the records the stand-alone SORT would have required.)

Hope this helps, and best of luck!

Steve Douglass
BFGoodrich Aerospace
-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]]On
Behalf Of Taale Liereng
Sent: Thursday, September 09, 1999 7:47 AM
To: [log in to unmask]
Subject: Running 1 or several batchjobs at the same time ?


The nights are to short for all my nightjobs !!

If I have to run a number of batchjobs during the night: which is the
faster way ?

- running one at a time, job #1 streams job #2, #2 streams #3 etc
or
- stream all the jobs at the same time


Anyone in experience ?

Taale Liereng
Merkantildata, Norway