Post by Franco Lombardoif the BCHTIMLMT is insufficient for the RCLSTG SELECT(*DBXREF)...
but I used BCHTIMLMT(*NOMAX), I think it would be a sufficient time
:-) or am I missing something?
I was trying to be generic in my comment, with regard to the reclaim
of the system Database Cross-Reference request being interrupted; i.e.
any interruption requires restarting the request, to recover. I
realize, by re-reading, my intended implication was not very clear. It
is correct, that the specific\shown *NOMAX would be sufficient to avoid
a timeout. However...
As I recall there are numerous /warnings against/ using *NOMAX
because the termination of the request requires a forced-pwrdwn from the
panel [or equivalent], if for any reason the request needed to be
terminated. While the concept of /no specific time limit/ is compatible
with computing and theory, the reality is that giving up the computer
for an indefinite amount of time is not generally an option; i.e.
realities of specific time-requirements trump the theoretical lack of
specific time-requirements. Because there is no feedback from the
request [as there could be, or means to inquire such as SysRqs-3, given
the request had instead been performed from a workstation], there is
limited means to know if two hours later, that the request is likely to
complete versus knowing if the request might be looping, hung, or in an
indefinite-wait [such as a deadlock].
Post by Franco LombardoWhat is unclear to me is your explanation of the "asynchronous"
behaviour of RCLSTG: does the command end while some of its work is
still running in system jobs? So, how could I understand when to end
the system? Maybe using
PWRDWNSYS OPTION(*CNTRLD)?
There is no *requirement* to avoid ending the system to allow the
asynchronous work to complete, because the QDBSRVXR* jobs must be able
to handle the termination without losing track of its work. The point
was merely to reveal that some amount of asynchronous work likely will
pend the system restarting.... and thus that background work restarts
after the system restarts, and thus any impacts from that pending work
may be experienced then. So *if* there is some benefit to knowing that
[most of the] work will be completed before the PwrDwn\restart...
I do not recall if there was a feature that was integrated into the
OS specifically to enable detection of the completion of the amount of
work for either job, but IIRC there are methods to detect at least that
the primary enqueued [queued-up] entries [those on the first queue] have
since been emptied; analogously, detecting the first of two pipes has
been drained. One of the following should suffice for a means to effect
a wait, until the first queue is emptied; in order of preference and
likelihood of effecting the wait:
- call the Retrieve Short Name (QDBRTVSN) API to request the
short\system name from a long-name; e.g. of SYSROUTINES in QSYS2
- create a long-name database file into a non-QTEMP [user] library
- create\add a constraint to a file in a [user] library
- rcldbxref *check /* may or may not by design, have a wait */
- the RDB Directory commands function on a timeout, so paired
ADDRDBDIRE\RMVRDBDIRE [or requests to CHGRDBDIRE] could be used to
implement a timed-wait polling.
These other requests below can be composed to detect if work remains
[though waiting would require coded-delay with loop\polling], from
either job, but depends on the implementation details; i.e. which named
queues... but no requirement to parse the output nor reverse-engineer
the counts, by using the known number or spool records to force the dump
request to fail if any messages were on the queue [and OVRDBF can be
used with a SIZE() limit on the database file but that is more complicated]:
- dmpsysobj qdbxrefq qsys 0a c4 /* limit MaxRcds with OVRPRTF */
- dmpsysobj qdbxrefq2 qsys 0a c4 /* limit MaxRcds with OVRPRTF */
- rcldbxref *check LIB(last_alphabetic) /* if no-wait per prv ref */
--
Regards, Chuck