On my R&D partition, I turned off the save of all spoolfiles (210,000 spoolfiles total over 130 outqs), save went from 3:15 down to 1:09, savings of 2+ hours.
This partition has 24 571 gb 10k SAS drives (12.5 tb), paired 5913 controllers
On my Production partition, also turned off save of all spoolfiles (240,000 spoolfiles total over 240 outqs) save went from 2:19 to 2:13, savings of only 6 minutes.
This partition has 18 177 gb SFF-2 SSD (2.8 tb), paired 5913 controllers
I want to reemphasize how much performance gain one can see with SSD drives and that the saving of spoolfiles on a system with conventional drives can be very slow.
I will be reconfiguring my BRMS spoolfile save strategy on my R&D partition.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Monday, February 10, 2014 7:37 AM
To: Midrange Systems Technical Discussion
Subject: Re: BRMS backup window increasing due to QUSRSYS/QEZJOBLOG
1 - We don't save spool files. I've tried to repeatedly drill into users (back when it wasn't easily supported by the OS) that they shouldn't rely upon spool files being there. The data should be relied upon. Granted, I understand that some spool files are transitional and hard to duplicate.
Even though it's now easier we still do not save spool files.
2 - We use the system value QLOGOUTPUT and changed joblogs to NOT spool up but instead go into 'pending' state instead. If you just 'have' to have a spool output (to send to IBM or whatever) you do a DSPJOBLOG JOB(...) OUTPUT(*PRINT).
3 - We use the GO CLEANUP menu to automatically delete these with GO CLEANUP 1. Change cleanup options Number of days to keep: Job logs and other system output . . . . . . . 7
4 - We delete all spool files after 90 days. No exceptions. Remember, with that QLOGOUTPUT set joblogs are not spool files unless someone does DSPJOBLOG OUTPUT(*PRINT).
Maintaining job logs for a long period of time:
- wastes disk space
- increases the number of jobs in your system, which can have it's own set of ill effects
- increases your backup time (and often your system outage) if you save spool files, and you have joblogs spool up.
- encourages sloth in dealing with problem issues.
Our busiest 'traditional' lpar has only 7 spool files in QEZJOBLOG. Only one was a 'traditional' application. The rest were qejbsvr type jobs.
Weird that something of IBM's would default to spooling output. Even if you don't change your system value IBM has changed many of their job descriptions to LOGOUTPUT(*PND).
Rob Berendt
--
IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com
From: "Steinmetz, Paul" <PSteinmetz@xxxxxxxxxx>
To: "'midrange-l@xxxxxxxxxxxx'" <midrange-l@xxxxxxxxxxxx>
Date: 02/07/2014 10:51 PM
Subject: BRMS backup window increasing due to QUSRSYS/QEZJOBLOG
Sent by: midrange-l-bounces@xxxxxxxxxxxx
Over the last several months, our BRMS changed object on R&D LPAR has
increased significantly.
A backup list which includes all libraries with outqs saves the outq and
spoolfile data.
QUSRSYS/QEZJOBLOG of 200,000 is taking 1 hour 40 minutes.
Does anyone else save spoolfiles, if so how, how many, and how long.
Thank You
_____
Paul Steinmetz
IBM i Systems Administrator
Pencor Services, Inc.
462 Delaware Ave
Palmerton Pa 18071
610-826-9117 work
610-826-9188 fax
610-349-0913 cell
610-377-6012 home
psteinmetz@xxxxxxxxxx
http://www.pencor.com/
midrange.com
