The "not saved" information is recorded in the joblog and\or the
OUTPUT(); the best information IMO is in the joblog. I would suggest
changing the GO SAVE option-21 processing to collect either or both;
e.g. adding OUTPUT(*PRINT) to the save request(s) and\or DSPJOBLOG
OUTPUT(*PRINT) at the (ab)normal exit-points.
_Determining objects that are not saved_
When the system cannot save an object, the system skips that object and
writes an entry to the job log. Verifying the job logs that the system
creates by your save procedures is very important. If you have very
large save operations, you might want to develop a program that copies
the job log to a file and analyzes it.
You can specify OUTPUT(*OUTFILE) INFTYPE(*ERR) on the SAVLIB, SAVOBJ,
and SAVCHGOBJ commands. This creates an output file that only contains
entries for those objects that the system did not save. Refer to the
online command help for more information about the specific command.
_Interpreting output from save commands_
You can use these save commands or APIs to direct output to an output file.
The control language (CL) provides descriptions for the three parameters
that allow you to direct save output to an output file: File to receive
output (OUTFILE), Output member options (OUTMBR), and Type of output
On 14-Mar-2014 08:28 -0700, Jon S wrote:
Oh yeah, I don't have a joblog, just DSPLOG.
rob on Fri, 14 Mar 2014 11:10:13 -0400 wrote:
DSPJOBLOG OUTPUT(*PRINT) browse the spool file. <<SNIP>>
Jon S on 03/14/2014 10:07 AM wrote:
I have a customer that's trying to run a GO SAVE #21 Entire System Save
and at the end they are getting CPF3777. The system is in a restricted
state and the only thing I can find that's not getting saved is the
<<SNIP>> 5 spooled files were not saved.
I have seen this with damaged objects before but never with spooled files.
Does anyone know what I can do about these spooled files and why they are
not getting saved?