× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



My nightly BRMS job starts at 11:00 pm and runs to about 3:00 am. When
finished an exit job runs to perform the following:

*PGM*

*DCLPRCOPT* DFTACTGRP(*NO) ACTGRP(*CALLER) BNDDIR(OIBLIB)

/*********************************************************************/

/* Start the BRMS media movement & print reports. */

/*********************************************************************/

MOVMEDBRM MOVPCY(TAPEMOVES) LOC(TAPMLB01)

/*********************************************************************/

STRMNTBRM PRTEXPMED(*NO) PRTVSNRPT(*NO) PRTBKUACT(*NO) +

PRTRCYRPT(*ALL) RGZBRMDB(*YES)

WRKMEDIBRM CTLGRP(DMCTCD) SLTDATE(*CURRENT) +

OUTPUT(*PRINT)

WRKMEDBRM SORT(*VOL) OUTPUT(*PRINT)

/*********************************************************************/

DSPJOBLOG OUTPUT(*PRINT)

*CALL* PGM(DMCBRMS/ZZBRMPDF)

/*********************************************************************/

EXIT:
*RETURN *

*ENDPGM*


Review of the job log shows that the following timeline:

STRMNTBRM - starts at 2:55 am
WRKMEDIBRM - starts at 12:46 pm

This timeline has been creeping up and I've been trying to determine the
culprit but so far I've not been able to find any cause of this.

I will add that we use the IFS for a significant amount of our work these
days, and it is backed up every night. For example on 11/18 I took a
snapshot of one folder (with several subfolders) and the properties of the
folder indicated that there were 262,570 files in 375 folders.

Also monthly I have a process that moves these files into archive folders
which are then zipped and also stored in the IFS. My thinking all along has
been that the brms process for indexing the files during brms maintenance
is what is taking so much time.

Then yesterday I ran the month end archive/zip process and was hoping to
see a bit of a reduction in the maintenance process today but it actually
took a few more minutes than it did yesterday.

Here is what the joblog is showing. Notice how the timestamp goes from
03:14:53 and then at the bottom of the snip it says 12:46:49. And after
that the joblog starts writing the reorg messages..


Cause . . . . . : The report with printer file name QP1A2SL was
created. I
contains 7
entries.
00 11/29/16 03:14:53.611719 QSYCHONR QSYS 0695
QLIINSRT
Message . . . . : Ownership of object Q1AMNTHALT in QUSRBRM type
*DTAARA

changed.
Cause . . . . . : The ownership of object Q1AMNTHALT in library
QUSRBRM ty
*DTAARA has
changed.
10 11/29/16 03:14:53.673918 Q1AMS QBRM *STMT
Q1ACXMNT
From module . . . . . . . . :
Q1AMS
From procedure . . . . . . :
send__11q1aMsgOS400FRC8I0StringQ2_10q1aMessa

10q1aMsgTypePviRiCQ2_10q1aMessage11q1aMsgStackRC15q1aBrmsQualName
Statement . . . . . . . . . :
278
To module . . . . . . . . . :
Q1ACXMNT
Job Log TCLINIC 11/29/16
12:46:29
DMCTCDX2 User . . . . . . : OIBADMIN Number . . . . . . . .
. .
OIBJOBD Library . . . . . :
OIBLIB

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.