Re: The problem with SAVCHGOBJ . . .

[CRPence <CRPbottle@xxxxxxxxx>]

James H. H. Lampert wrote:
> The problem with SAVCHGOBJ is that if you do a SAVCHGOBJ, and it 
> finds a library that's never been saved, it doesn't save it, or
> anything in it.
>
> Not being in any mood to reinvent that particular wheel, has 
> anybody set up any sort of "enhanced SAVCHGOBJ," e.g., a CL 
> program that does a SAVCHGOBJ, then goes through and saves the 
> libraries that the SAVCHGOBJ missed?
>
> <<SNIP>>

  - Consider /enhancing/ the CRTLIB instead; e.g. to either issue 
or schedule a SAVLIB.?  Rather than intercepting the CL command 
CRTLIB, activating the save could be in response to some object 
auditing; e.g. T-CO entry for the object type *LIB.

  - Another relatively simple approach is to, just before the 
SAVCHGOBJ request, list the object details of the *LIB objects 
target of the upcoming SAVCHGOBJ request, e.g. from the request to:

   DSPOBJD *N/*ALLUSR *LIB *FULL
           OUTPUT(*OUTFILE) OUTFILE(QTEMP/ODUSRLIBS)

  And then e.g.

   SELECT ExecCmd('SAVLIB ' CONCAT ODOBNM CONCAT SavlibParms())
   FROM QTEMP/ODUSRLIBS
   WHERE ODSDAT=''

  The given SELECT alludes to effecting, after having issued within 
the job CRTSAVF QTEMP/NULLSAVF, something like:

     SAVLIB EachUnSavedLibNam *SAVF SAVF(QTEMP/NULLSAVF)
            CLEAR(*ALL) UPDHST(*YES) OMITOBJ((*ALL *ALL))

  - Since a message is supposed to be issued when REFDATE(*SAVLIB) 
is specified\defaulted but the library was never previously saved, 
the reactive approach by review of either SAVCHGOBJ OUTPUT(*OUTFILE) 
results or DSPJOBLOG OUTPUT(*OUTFILE) results for any library that 
would benefit from an explicit SAVLIB request would not seem so 
complex as to be concerned with reinventing the wheel.?

Regards, Chuck