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.?

Return to Archive home page | Return to MIDRANGE.COM home page