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

Related ...

This thread ...


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