Tim,
to explain WHY I give the upcomiong advises, first some theory about the algoritms of BACKUP. It is implemented this way to agressively optimise for speed, but it has some consequences.
BACKUP essentially works in 4 phases: an initial one, and then a cycle of 3.
First, it creates the list of header-info of things-to-do. In case of /IMAGE, simply by processing INDEXFILE.SYS.
All now still available WorkingSet space is allocated for the transfer-buffer.
Now, phase 2: things-to-do is used to _ONLY_ map the files-to-be-processed (more exactly: the file EXTENTS) into the transfer buffer, and build a list of I/O-info for these segments.
This phase continues until the first of:
- transfer-buffer exhausted => that is why a large-as-possible WSQUOTA is benificial.
- the number of files (minus process-permanent files, minus image files, minus shared images) reaches FILLM => this is why if you are processing many small files FILLM should be high enough
- the number of file segments (minud dito for the above) reaches CHANNELCNT => which is why CHANNELCNT should be high enough, especially when processing small and/or fragmented files.
Phase 3: Try to isssue the I/O requests for ALL file extents at once. Number of requests limited by DIOLM. This forces the diskdrive into "heavy-load" mode, which means that no longer I/O's are processed as first-come-first served, but help-as-many-as-possible-as-quick-as-possible. Ie., sweep the disk from one end to the other, and process all requests for every track the heads pass by. This minimises seektime, the largest delay in getting data from disk. Each extent goes into the location in the transferbuffer that leads to a contigues chunck when all extents are in. => This shows why DIOLM must be high enough: if the amount of I/O requests to handle this buffer is lager than BIOLM, then we need more than one disk-sweep.
Phase 4: (Do the necessary calculations for CRC, conversion to Backup-format etc) and: Issue ONE I/O of the TOTAL tranfer buffer to tape. (although at a lower level the hardware may still split up your transfer, but then you are really using your config at the hardware capacity!)
And especially in tape-units that require a relative long time for start and stop, the size of this chunck can have an important influence on elapsed time.
Name back to phase 2 until finished.
Of course there are some caveats: if WSEXTENT is bigger than WSQUOTA, the working set may expand and shrink, and then the tranfer buffer can no longer be held logically contiguous, and paging will interfere (very detremential!) with the above scheme. => WSEXTENT and WSQUOTA should be equal. (and watch out for (sysgen) WSMAX:
that could top of part of the working set into paging if lower than WSQUOTA.
And of course physical memory should not be so restricted that part of the working set will be in the PAGEFILE!!!
So, now back to YOUR params.
FILLM 128. If many small files are involved, I would be thinking more in terms of 1024 or 4096.
CHANNELCOUNT double the FILLM of your backup account, if many heavily fragmented files, quadruple.
I would also increase BYTLM, to the order of 1M or 2M. It is not in the above discussion because I don't exactly now how it influences BACKUP, but I often found srange behaviour when it was too low (cant remember specifically for Backup, though)
A word of warning IF you (or any other reader) applies this to HSG80-connected devices: those have a rather limited maximum IO queue length, (out of my head: 240 IIRC) and there IS an issue in some firmware versions that if it gets saturated it just goes mad, and forgets to present the disks to the systems. VERY painfull.
Antonio:
since this is the only active process, I don't think PRIO=15 can give you any advantage, although I cannot right now think of how it might hurt eigther.
SET PROCESS /NOSWAP will have very little effect, since an applic as agressive as Backup is not really a swap-out candidate (unless it is waiting for a device that is not ready, but then there are other problems first)
Well Tim,
I guess that will have to do for now.
Success!
Jan
Don't rust yours pelled jacker to fine doll missed aches.
