Paul:
With all of my customers that run Zend Server I omit those files during the
daily saves.  You will need them in a recovery, but the data in them are
used by the Zend Server for deployments and debug.  Generally I will shut
down to a restricted state (monthly or quarterly) and that's the copy of
those we use for recoveries.  The deployments database is the most critical,
but unless your development team is using the Zend Server Deployment
features on a regular basis, it's fairly static data. 
This technique has been tested at two customers and seems to fit the bill.  
--
Jim Oberholtzer
Agile Technology Architects
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob
Berendt
Sent: Friday, October 28, 2016 9:37 AM
To: Midrange Systems Technical Discussion
Subject: RE: BRMS recovery report questions/issues
If you change the "can be saved" the odds are the darn things will just be
locked.  I would guess that whomever changed that attribute knew what they
were doing and deemed them expendable.
Trust me, when you go to 7.2 expect to have the "can be saved" increased
into the hundreds.
Add them to the BRMS omits.
Granted, when you run your dedicated save with OMITS(*IGNORE) they will,
once again, appear on your list.
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:   10/28/2016 10:30 AM
Subject:        RE: BRMS recovery report questions/issues
Sent by:        "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
Rob,
1) I think I found the answer.
I reran the recovery report with USEDUPMED(*YES).
Not only does this resolve the issue with the old volumes, but it also 
changes the message for Step 1 and Step 2.
Reason being my current system save is from a DUPMEDBRM, not the original 
volume, so USEDUPMED(*YES) changed the message.
2) The only remaining issue is to resolve
 -----  Attention  --------------------------------------------------- 
The recovery includes 000000000000029 objects which were not saved. 
The count matches the count from *LINK, 29 Not saved.
   Saved      Save    ----- ASP ------  Save     Save             Not 
Sequence  Control    Volume 
   Item       Type    Name      Number  Date     Time    Saved    Saved 
Number    Group      Identifier                   Encrypt 
   ---------- ------- ---------- ----- -------- -------- -------- ------ 
--------- ---------- ---------------------------- ------- 
__ *LINK      *FULL   *SYSBAS    00001 10/27/16 23:23:55   237625     29   
 262 SAVFULL05  001333 
Next I searched the joblog from last night's save for  CPFA09E - Message . 
. . . :   Object in use.  Object is
Found 29 CPFA09E.
Of the 29 - 25 were www log files and other log files.
The remaining 4 which were not log files are:
/QIBM/UserData/OS400/TCPIP/NTP/QTOT20161027.
/usr/local/zendsvr/var/db/deployment.db 
/usr/local/zendsvr/var/db/monitor
/usr/local/zendsvr/var/db/monitor_codetracing
Should add more omits or change Can be saved . . . . . . . . . . . . . : 
No.
????
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Rob 
Berendt
Sent: Friday, October 28, 2016 9:02 AM
To: Midrange Systems Technical Discussion
Subject: RE: BRMS recovery report questions/issues
Not so sure.  That may be normal.
I bring down my systems nicely.  Then I do the ENDSBS *ALL *CNTRLD 
DELAY(120).  After I verify that the system is in restricted state I do my 
STRBKUBRM.  It always starts some stuff up.  I suspect, even if I have 
plenty of tapes on this lpar, it still wants to talk to the other lpars 
and systems as part of the BRMS Network Feature.  I know some TCP gets 
going.  This wastes a couple of minutes.  Then it shuts stuff down again 
and gets back into restricted state.
Keep digging.
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:   10/27/2016 04:42 PM
Subject:        RE: BRMS recovery report questions/issues
Sent by:        "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>
Maybe a BRMS timing issue.
*NONE      Request                      10/22/16  22:03:02.352136 QWTSCSBJ 
                *N       QCMD        QSYS        0195
                                     Message . . . . :  -STRBKUBRM 
CTLGRP(SAVSYS05) SCDTIME(*IMMED) SBMJOB(*NO) 
                                       STRSEQ(*FIRST *FIRST) APPEND(*YES) 
ACTIVITY(*CTLGRPATR) RETENTION(*CTLGRPATR 
                                       0035) DEV(*CTLGRPATR) 
PRLRSC(*CTLGRPATR *MIN) MEDCLS(*CTLGRPATR) 
                                       MOVPCY(*CTLGRPATR) OMITS(*IGNORE) 
 
BRM1148    Information             10   10/22/16  22:05:50.592390  Q1ACALG 
     QBRM        *STMT    Q1ACALG     QBRM        *STMT
                                     From module . . . . . . . . : Q1ACALG 
 
                                     From procedure  . . . . . . : Q1ACALG 
 
                                     Statement . . . . . . . . . :   229 
 
                                     To module . . . . . . . . . : Q1ACALG 
 
                                     To procedure  . . . . . . . : Q1ACALG 
 
                                     Statement . . . . . . . . . :   229 
 
                                     Message . . . . :   Item *SAVSYS will 
be saved using serial device resources. 
BRM1081    Information             00   10/22/16  22:05:51.561941  Q1ACALG 
     QBRM        *STMT    Q1ACALG     QBRM        *STMT
                                     From module . . . . . . . . : Q1ACALG 
 
 5770SS1 V7R1M0 100423                           Job Log  PENCOR05 
10/22/16 23:09:10          Page    6
  Job name . . . . . . . . . . :   SAVSYS05        User  . . . . . . : 
ICAPICTL     Number . . . . . . . . . . . :   989607 
  Job description  . . . . . . :   CM_SHORT        Library . . . . . : GPL 
 
MSGID      TYPE                    SEV  DATE      TIME             FROM 
PGM     LIBRARY     INST     TO PGM      LIBRARY     INST 
                                     From procedure  . . . . . . : Q1ACALG 
 
                                     Statement . . . . . . . . . :   229 
 
                                     To module . . . . . . . . . : Q1ACALG 
 
                                     To procedure  . . . . . . . : Q1ACALG 
 
                                     Statement . . . . . . . . . :   229 
 
                                     Message . . . . :   Starting SAVSYS 
to devices TAPMLB01. 
22:06:11
ENDSBS SBS(*ALL) command being processed.
System ended to restricted condition. 
Paul
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of 
Marc Rauzier
Sent: Thursday, October 27, 2016 4:09 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: BRMS recovery report questions/issues
Le 27/10/2016 à 21:23, Steinmetz, Paul a écrit :
Here's some additional issues
If I just did a system save, why am I seeing this on the BRMS recovery 
report.
Stating both LIC and OS has NOT been saved.
Are you sure that the system was in restricted state when the SAVSYS 
through BRMS control group took place ?
Marc
--
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.
Please contact support@xxxxxxxxxxxx for any subscription related 
questions.
As an Amazon Associate we earn from qualifying purchases.