When you do a SAVLIB of that library for your FTP transmission, if you say
Update History *NO, your SAVCHGOBJ will work.
I am not a big fan of SAVCHGOBJ at all, as it makes restores much more
difficult, and I have found in tests that when *MOST* of the objects change
in a library, you are better off using SAVLIB than SAVCHGOBJ.
Also, you are right about using the Reference Date and supplying a date, it
works much better, plus if you create a new library and never back it up
with a SAVLIB command, then your next SAVCHGOBJ command will never backup
the library or any objects in there (doesn't matter if they changed or not)
if you are using REFDATE(*SAVLIB).
JMHO
Pete
Pete Massiello
iTech Solutions
http://www.itechsol.com
Add iTech Solutions on Facebook:
http://www.facebook.com/group.php?gid=126431824120
Add iTech Solutionw on LinkedIn:
http://www.linkedin.com/groups?gid=2206093
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of phil.seay@xxxxxxxxxx
Sent: Tuesday, December 01, 2009 1:12 PM
To: Midrange Systems Technical Discussion
Subject: RE: : Best Way to Check if a Library Has At Least 1 Changed Object
There is one little caveat about using REFDATE(*SAVLIB). If you save the
library in your backup procedure and then later save the library for some
other reason (for example, to a save file for FTP transmission to another
machine), you probably aren't getting the REFDATE you want. I use SAVCHGOBJ
for my daily saves and specify a date-time that was saved in a data area
during the last backup SAVLIB.
Regards,
Philip Seay
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Friday, November 27, 2009 12:44 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: : Best Way to Check if a Library Has At Least 1 Changed Object
FWiW the DSPOBJD is potentially a very expensive method to
determine "if a library has at least one changed object". I would
use a SAVCHGOBJ with its default of /since last full save/ [i.e.
REFDATE(*SAVLIB)] to determine the answer to the question; of course
with that criteria of since when. This can be effected with
probably fewer resources by limiting the actual capabilities of the
save request by using a DEV(*SAVF) created with CRTSAVF MAXRCDS(1).
Using this method, a save which has at least one object will fail
with Diag CPF3808 and Escape CPF3815 indicating the maximum number
of records was exceeded. A save which has no objects will
/complete/ without saving any objects, then issuing the completion
CPC3708 suggesting "all object excluded" for the given reference
date\time. For example, using the command strings like:
===> CRTSAVF QTEMP/CHGTEST MAXRCDS(1)
===> SAVCHGOBJ OBJ(*ALL) LIB(&LIBNAME) DEV(*SAVF) OBJTYPE(*ALL)
OBJJRN(*YES) REFDATE(*SAVLIB) SAVF(QTEMP/CHGTEST) UPDHST(*NO)
CLEAR(*ALL) PRECHK(*NO) SAVACT(*NO) ACCPTH(*NO) SAVFDTA(*YES)
DTACPR(*YES) OMITOBJ((&LIBNAME/*ALL *JRN)) OUTPUT(*NONE) /* may want
to include output queue data selection as well */
Regards, Chuck
Richard Schoen wrote:
Looks like either the DSPOBJD method or Vern mentioned object
auditing. I'm going to check into that as well.
Peter Vidal wrote:
Probably you can do something like : DSPOBJD OBJ(PVIDAL)
OBJTYPE(*LIB) OUTPUT(*OUTFILE) OUTFILE(QGPL/LIBSTATUS)
After 24hrs you can do something like: DSPOBJD OBJ(PVIDAL)
OBJTYPE(*LIB) OUTPUT(*OUTFILE) OUTFILE(QTEMP/CURLIBSTS)
You can compare the 2 files via the object name and compare
maybe these 2 fields: ODLDAT - Change date (MMDDYY) ODLTIM -
Change time (HHMMSS)
If you determine that these fields are different between the
two, you can back this library up.
Finally, make sure that QTEMP/CURLIBSTS gets copied over
QGPL/LIBSTATUS.
Just a quick thought.... not tested obviously....
midrange.com
