×
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.
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.?
midrange.com
