Re: Opt 21 Restore

On 07-Nov-2014 14:24 -0600, rob@xxxxxxxxx wrote:

One of the potential pitfalls of CPYSPLF is word wrapping. Search
for "not restored" and what happens if "not" is on one line and
"restored" is on the next.

Every issue that comes with "screen scraping" is likely also to be a an issue with copying spooled data to a fixed-record-length file or stream file to use as input to a program that parses\processes that /scraped/ data. There are a number of other potential problems with searching on "not restored"; I have posted some examples, twice, over the last several days that are archived with this list\group.

With the *OUTFILE option you don't get the whole message. You get
the message number and the message data. IOW you are not going to
find "not restored" but you could find the message id that contains
that text. Message id may vary based on DB2 file, stream file, etc.
Not insurmountable, just something to be aware of.

That is a reason the RSTLIB OUTPUT(*OUTFILE) might be better for the purpose expressed, than the use of DSPJOBLOG OUTPUT(*OUTFILE); i.e. a first pass looking for exceptions, to find out what to examine more thoroughly in the spooled joblog.

But of course a UDF could build the text if there was interest in searching the actual message text. Yet as already noted, searching the "text" of the message, esp. limited to just "not restored", is a poor choice. If using the externally described database output file from the RSTxxx command, there should be a column\field that identifies the condition sufficiently as effectively "not restored"; of course, that would be irrespective the existence of any [portion of the] text including the string "not restored".

And what gives with not being able to specify a job id other than
JOB(*) when using the *OUTFILE option?

My thoughts originally, as well. But I seem to recall realizing or rationalizing why not, although I can not recall what that might have been.