RE: BRMS backup window increasing due to QUSRSYS/QEZJOBLOG -- MIDRANGE-L

Rob,

On Production, 90 days of joblogs, this keeps about 230,000 jobs in the system
On R&D, was 90 but had to increase to 180, keeps about 130,000 jobs in the system.
Software upgrade and testing logs were being lost.
IBMS's clean up tasks runs daily to purge the above and other system items.

We also created an automated utility (DLTOLDSPLF) that runs daily via AJS that purges spoolfiles from an outq based on a predetermined number of days.
We default all outqs to 45 days, but if a certain outq needs more or less, we set the number of days in the outq's user defined option field.
User defined option . . . . . . '999 '
User defined option . . . . . . '10 '

We use system API QSPROUTQ to retrieve this value.
CALL PGM(QSPROUTQ) PARM(&RCVINF &RCVLEN &FORMAT +
&OBJLIB &APIERR)

We then use TAATOOL DLTOLDSPLF to delete any spoolfile greater than the number of days retrieved for that outq.

DLTOLDSPLF OUTQ(&ODLBNM/&ODOBNM) FILE(*ALL) USER(*ALL) +
JOB(*ALL) EXCLUDEJOB(*NONE) +
FORMTYPE(*ALL) USRDTA(*ALL) STS(*ALL) +
ASPDEV(*) RETAINDAYS(&RETENTION) +
QPJOBLOG(999) QPSRVDMP(999) +
MOVTOOUTQ(*LIBL/*NONE) ACTION(&ACTION) +
COMPDATE(*CRTDAT) SUMMARY(*YES)

With the combination of above, all spoolfiles are auto purged, keeping the system clean, but there if needed for auditing and troubleshooting requirements.
Once In a blue moon, we may need to restore an outqs spoolfiles.

Paul

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of rob@xxxxxxxxx
Sent: Wednesday, February 12, 2014 7:08 AM
To: Midrange Systems Technical Discussion
Subject: RE: BRMS backup window increasing due to QUSRSYS/QEZJOBLOG

Just how long are you retaining joblogs?

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 Systems Technical Discussion'"
<midrange-l@xxxxxxxxxxxx>
Date: 02/11/2014 08:53 PM
Subject: RE: BRMS backup window increasing due to QUSRSYS/QEZJOBLOG
Sent by: midrange-l-bounces@xxxxxxxxxxxx

I reconfigured the R&D save to save all spoolfiles, excluding
qusrsys/qezjoblog, save time is now 1:35..
In order to accomplish this:
1) I had to remove qusrsys from the object list, OUTQSLCCFG *OBJ, I had
created for libraries containing outqs.
2) Added a control group item qusrsys.
3) Using Ops Navigator, added an omit item, qezjoblog *outq for the new
qusrsys control group item.

-----Original Message-----
From: Steinmetz, Paul
Sent: Tuesday, February 11, 2014 10:02 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: BRMS backup window increasing due to QUSRSYS/QEZJOBLOG

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/

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.