RE: RSTLIBBRM failed due to "false" DFRID

Had another reoccurrence of this issue - CPI373C
Reopened PMR with IBM.
Currently the job is looping, waiting for must gather info.
Another customer has similar issue, PTF in the works
On the restore of QRPLESRC to an empty library, the following occurred, setting on the DFRID flag.
For unknown reasons, journaling is trying to start, but the file was not journaled to begin with.
All future RSTLIBRM will fail, until DFRID is cleared - QSYS/RMVDFRID DFRID(*ALL)
Database team also involved.
Has anyone else experienced this or similar issue?

Personally, I hate the DFRID option that was forced on us back in V6R1.
I recommended a BRMS data area to be able to control if you wish to use this option.
For us, it has been all negative, no benefit.

CPC2206 Completion 00 07/23/14 14:36:29.769089 QSYCHONR QSYS 0695 QLIINSRT QSYS 051B
Message . . . . : Ownership of object Q1ADDMOK in QTEMP type *DTAARA
changed.
CPC2206 Completion 00 07/23/14 14:38:43.792842 QSYCHONR QSYS 0695 QLIINSRT QSYS 051B
Message . . . . : Ownership of object QRSTOBJSPC in QTEMP type *USRSPC
changed.
BRM1669 Information 10 07/23/14 14:38:45.533508 Q1ACALG QBRM *STMT Q1ACALG QBRM *STMT
From module . . . . . . . . : Q1ACALG
From procedure . . . . . . : Q1ACALG
Statement . . . . . . . . . : 229
To module . . . . . . . . . : Q1ACALG
To procedure . . . . . . . : Q1ACALG
Statement . . . . . . . . . : 229
Message . . . . : Devices TAPMLB01 will be used for control group *N type
*RCY.
CPF3281 Information 10 07/23/14 14:39:53.790951 QDBRSPRE QSYS 17FA QDBRSPRE QSYS 17FA
Message . . . . : New format QRPGLESRC created for file QRPGLESRC.
CPF3294 Information 40 07/23/14 14:39:54.184154 QDBRSPRE QSYS 17FA QDBRSPRE QSYS 17FA
Message . . . . : Cannot start journaling for member *N.
CPF3292 Information 10 07/23/14 14:40:50.364691 QDBRSPST QSYS 0814 QDBRSPST QSYS 0814
Message . . . . : File QRPGLESRC in library JOHNSTEMP restored.
CPI373C Information 10 07/23/14 14:41:38.542942 Q1AC2HS QBRM *STMT Q1AC1OD QBRM *STMT
From module . . . . . . . . : Q1AC2HS
From procedure . . . . . . : Q1AC2HS
Statement . . . . . . . . . : 435
To module . . . . . . . . . : Q1AC1OD
To procedure . . . . . . . : Q1AC1OD
Statement . . . . . . . . . : 1055
Message . . . . : DFRID Q1ARSTID has 1 objects remaining.
CPC2206 Completion 00 07/23/14 14:41:42.299433 QSYCHONR QSYS 0695 QLIINSRT QSYS 051B
Message . . . . : Ownership of object QBRMSPC_ in QTEMP type *USRSPC
changed.
CPF9810 Escape 40 07/23/14 14:41:42.863154 QJOJRNPF QSYS 0545 QDBRSDFR QSYS *STMT
To module . . . . . . . . . : QDBRSDFR
To procedure . . . . . . . : RESTORE_DEFERRED_STRJRN
Statement . . . . . . . . . : 8661
Message . . . . : Library not found.
Job name . . . . . . . . . . : PALPR5506B User . . . . . . : GDEPUE Number . . . . . . . . . . . : 959898
Job description . . . . . . : PRODUCT Library . . . . . : GPL
MSGID TYPE SEV DATE TIME FROM PGM LIBRARY INST TO PGM LIBRARY INST
CPI9871 Information 20 07/23/14 14:41:42.872268 QDBRSDFR QSYS *STMT QSRRSDFR QSYS 005D
From module . . . . . . . . : QDBRSDFR
From procedure . . . . . . : QDBGEN_SEND_PGM_MSG
Statement . . . . . . . . . : 6905
Message . . . . : Cannot start journaling for object QRPGLESRC.
CPF3848 Diagnostic 20 07/23/14 14:41:42.993145 Q1AC1RCY QBRM *STMT Q1ARHS QBRM *STMT
From module . . . . . . . . : Q1AC1RCY
From procedure . . . . . . : Q1AC1RCY
Statement . . . . . . . . . : 494
To module . . . . . . . . . : Q1ARHS
To procedure . . . . . . . : Q1ARHS
Statement . . . . . . . . . : 4122
Message . . . . : 1 security or data format changes occurred.
CPF3773 Diagnostic 20 07/23/14 14:41:42.993308 Q1AC1RCY QBRM *STMT Q1ARHS QBRM *STMT
From module . . . . . . . . : Q1AC1RCY
From procedure . . . . . . : Q1AC1RCY
Statement . . . . . . . . . : 494
To module . . . . . . . . . : Q1ARHS
To procedure . . . . . . . : Q1ARHS
Statement . . . . . . . . . : 4122
Message . . . . : 1 objects restored. 0 not restored to JOHNSTEMP.

Paul

-----Original Message-----
From: Steinmetz, Paul
Sent: Wednesday, May 28, 2014 5:36 PM
To: 'midrange-l@xxxxxxxxxxxx'
Subject: RE: RSTLIBBRM failed due to "false" DFRID

Open PMR with IBM.
IBM has other reported similar issues intermittently over the last 6 months, both V6R1 and V7R1, They are still trying to have someone gather the needed data when the error occurs.
1) Library QRECOVERY
2) BRMS flight recorders
3) Joblog.

QRECOVERY/QADBRSDFRJ PF is possibly getting incorrectly updated, possible code issue.
QADBRSDFRJ is where the DFRID is stored.

Paul


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Wednesday, May 28, 2014 5:17 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: RSTLIBBRM failed due to "false" DFRID

On 28-May-2014 08:09 -0500, Steinmetz, Paul wrote:

Did anyone every experience a "false" DFRID on a RSTLIBBRM?
CPI3737 followed by CPF9810, CPI9871

Without the spooled joblog, I am not sure I understand what is implied here. With a web search, I get conflicting information about what the CPI9871 is, and in any case, I have no context for any of the messages without the joblog; ideally, including the prior request message [and any other message referencing the object named in the CPI3737, if any more than those noted].

I had one this morning, RMVDFRID *all cleared the issue.

The object identified by CPI3737 would seem to have been properly cleared of a condition of existing with a Deferred Identifier, as a result of the noted Remove Defer ID (RMVDFRID) having been performed.
In my estimation, that actually supports the prior receipt of CPI3737, as being accurate; i.e. a legitimate, rather than bogus [or "false"], condition.

In a past message a statement suggested that the BRMS does not provide an interface to specify a Deferral Identifier, and that the BRM restore commands implicitly performs Deferred Identifier production and thus DFR identifier processing when required; i.e.
<http://archive.midrange.com/midrange-l/201402/msg00756.html> "IBM does not provide the DFRID parameter on the RSTLIBBRM command. Under the covers a RSTLIB issued with DFRID set on by default." As such, it seems possible a restore did ask for and produce a deferred restore, and thus the Remove Defer ID (RMVDFRID) request was an alternate recovery to the Restore Deferred Objects (RSTDFROBJ) request.?

--
Regards, Chuck
--
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.