On 28 May 2012 17:03, Darryl Freinkel wrote:
I still do not understand why when I DSPJRN to an outfile, it
ignores the records I need to restore.
It seems that if the original member does not exist in the physical
file, then the DSPJRN ignores all records for that member. Manually
creating the member does not help. The member is created with
different ID's and so the member's records are not copied to the
OUTFILE. I have tried many options with the command parms without
When the DSPJRN parameters name a specific file or member, then the
request is implicitly asking to process only the entries from the
Journal Identifier (JID) associated with that file[.mbr]. The JID is
what ensures the entries apply to the proper entity. The member that
was previously deleted could be restored, and then the DSPJRN
FILE(named) would show the entries from that [since restored] member.
This nuance is in effect, for consistency with APYJRNCHG; i.e. what is
displayed for that member, is what could be applied to that member.
Thus if processed according to recovery of that data, by restore of the
[file and] member, the data should be available for the FILE((named_file
I am not sure, but I think the DSPJRN FILE((named *ALL)) will show
the entries even for the deleted member(s) of the named database file.
I can not check\test at the moment.
Apart from restoring the records from the journal, I need to copy
the records from the journal into a different file which is then
used for analysis.
So the entries can be seen, and thus recovered.? That instead, the
issue is just that certain invocation(s) of DSPJRN are not being
forthcoming with the desired entries.?
If so, then as I alluded in the prior reply, use a DSPJRN with
parameter specifications that allow the desired data [and probably more
than desirable] and select the entries specific to the member; e.g.
using a SELECT [in a VIEW].